The Inbox: PreferenceBrowser-ck.85.mcz
Locked
 
|
A new version of PreferenceBrowser was added to project The Inbox:
http://source.squeak.org/inbox/PreferenceBrowser-ck.85.mcz ==================== Summary ==================== Name: PreferenceBrowser-ck.85 Author: ck Time: 18 December 2019, 9:22:49.829611 am UUID: 1484d057-814b-4fb8-8d02-9b28797cf917 Ancestors: PreferenceBrowser-eem.84 Simple typo fix adding a space in the confirmation dialog. =============== Diff against PreferenceBrowser-eem.84 =============== Item was changed: ----- Method: PreferenceBrowser>>defaultSelected (in category 'preferences search') ----- defaultSelected + (Project uiManager confirm: 'Do you really want to restore the default\preferences?\\If you want to keep the current state,\you have to save it first.' translated withCRs title: 'Restore Preferences') + ifFalse: [^ self]. - - (Project uiManager - confirm: 'Do you really want to restorethe default\preferences?\\If you want to keep the current state,\you have to save it first.' translated withCRs - title: 'Restore Preferences') ifFalse: [^ self]. - - Preferences chooseInitialSettings! |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
Please don't put this dust into the trunk ancestry. Does anyone have anything else for the PreferencesBrowser they could include this with..? On Wed, Dec 18, 2019 at 2:22 AM <[hidden email]> wrote: A new version of PreferenceBrowser was added to project The Inbox: |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
* Chris Muller <[hidden email]> [191218 22:45]:
> Please don't put this dust into the trunk ancestry. Does anyone have > anything else for the PreferencesBrowser they could include this with..? I am sorry, how should I deal with these mini things in the future? -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
Hi Christian, My request to not include it in trunk as-is was directed at the trunk committers, you have no need to apologize. I'm glad you got to go through the lifecycle of contributing to Squeak including making a version and submitting it to our shared inbox repository. Good question though, the best way to deal with micro improvements is to... (wait for it...).. not. Seriously, stopping to package up a piece of micro dust just breaks your momentum. Just keep working toward your broader goal, don't worry about changes accumulating, saving your image at the end of the day with dirty packages is the normal case. When your meaingful-unit-of-improvement is ready to present to the world, craft your Version entries with the same care for clarity and compactness as you did the code, as if your name will forever be associated with this piece of work, since, it will. Welcome to Squeak. I look forward to your future contributions which will be worth reading about. Best, Chris On Wed, Dec 18, 2019 at 3:58 PM Christian Kellermann <[hidden email]> wrote: * Chris Muller <[hidden email]> [191218 22:45]: |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
Hi Chris,
* Chris Muller <[hidden email]> [191218 23:53]: > Welcome to Squeak. I look forward to your future contributions which will > be worth reading about. Thanks for the explanation and the warm welcome, I am still picking up the spirit and culture of this place as I go along! I'll try to make myself useful around here ;) -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
In reply to this post by Chris Muller-3
I actually have similar problems. I understand that we want to keep the history short, but, for example, I found some typos in a package some months ago but don't have any real contributions for this package. So, apparently, the world will never be released from these typos ... In other words, imho your approach of "waiting for a meaningful unit of improvement" does not scale optimally. :)
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Mittwoch, 18. Dezember 2019 23:52:52 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: PreferenceBrowser-ck.85.mcz Hi Christian,
My request to not include it in trunk as-is was directed at the trunk committers, you have no need to apologize. I'm glad you got to go through the lifecycle of contributing to Squeak including making a version and submitting it to
our shared inbox repository.
Good question though, the best way to deal with micro improvements is to... (wait for it...).. not. Seriously, stopping to package up a piece of micro dust just breaks your momentum. Just keep working toward your broader goal,
don't worry about changes accumulating, saving your image at the end of the day with dirty packages is the normal case. When your meaingful-unit-of-improvement is ready to present to the world, craft your Version entries with the same care for clarity and
compactness as you did the code, as if your name will forever be associated with this piece of work, since, it will.
Welcome to Squeak. I look forward to your future contributions which will be worth reading about.
Best,
Chris
On Wed, Dec 18, 2019 at 3:58 PM Christian Kellermann <[hidden email]> wrote:
* Chris Muller <[hidden email]> [191218 22:45]:
Carpe Squeak!
|
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
> In other words, imho your approach of "waiting for a meaningful unit of improvement" does not scale optimally. :) Exactly. That's why we need a different strategy and improve the "back end" that manages that history. I can clean out my local "package-cache" if I need more space on my disk. But I cannot improve the "browse revisions" feature from where I sit. :-) Best, Marcel
|
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
In reply to this post by Christian Kellermann
Christian
> On 18.12.2019, at 22:58, Christian Kellermann <[hidden email]> wrote: > > * Chris Muller <[hidden email]> [191218 22:45]: >> Please don't put this dust into the trunk ancestry. Does anyone have >> anything else for the PreferencesBrowser they could include this with..? > > I am sorry, how should I deal with these mini things in the future? Like you did. I think it's a perfectly valid commit. :) Best regards -Tobias |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
Chris wants a clean history with _meaningful_ chunks of changes. Other people want commits to be discrete/isolated changes, where "fixing typos" is one kind of change. (*) Everyone wants an efficient version control system. Also: code is easy to change, while people are very hard to change. Wikis have handled this for decades with a "minor edit" flag. (PhpWiki certainly had it in the last century.) If Monticello commits had such a concept, Chris could say "please don't show me dust" and other reviewers could demand "separate out the typo fixes from the interesting changes". I'm sure there are interesting technical discussions to be had, but my meta-point is this: quit arguing about process and invest in the tools and everyone can get what they want. frank (*)
I'm in this camp: refactors, behaviour changes, typo fixes should be in separate chunks, because I spend too much time reviewing code. At work I have the privilege of rejecting commits that don't meet these rules, and I'm not shy in using that privilege. And I encourage my staff to do the same. On Thu, 19 Dec 2019 at 02:56, Tobias Pape <[hidden email]> wrote: Christian |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
In reply to this post by marcel.taeumel
Hi Christoph, > In other words, imho your approach of "waiting for a meaningful unit of improvement" does not scale optimally. :) Your example has nothing to do with scaling. There's no "time-limit" for committing. All that matters is, either the cumulative changes you have waiting on a package have exceeded a threshold of "meaningful" or they haven't. A single one character change to a literal isn't meaningful enough, no matter how long ago it was done. And, I don't buy that there aren't plenty more improvements to be made, like comments and categorizations, within the same package, which could be committed a "fix pack".
Hi Marcel, allow me to share this same analogy: if our Squeak journey represents a vacation, and on our first day already we've taken hundreds and hundreds of pictures, including the McDonalds we stopped at for lunch (uninteresting), but then only came away with 10 or so pictures of the Grand Canyon (interesting), it doesn't matter if we have a 10TB hard drive back home (which, we don't) to dump them to, it's the volume of those uninteresting objects that has obscured the overall narrative of the vacation and spoiled the "domain". I try to review all packages. Time is at a premium, and I bet it is for you, too. We should cultivate and review only interesting objects which are worth the time to review. Best, Chris |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
In reply to this post by Frank Shearar-3
On Thu, Dec 19, 2019 at 10:38 AM Frank Shearar <[hidden email]> wrote:
I want that too, just not micro-sized singles. **There's plenty to do** in every package, please include a couple more non-critical typo's, categorizations, comments, or obvious bug-fixes, and submit it as a "fix pack". The contents should be more significant than the packaging that wraps it, not less.
Interesting. Something like that could be helpful. Maybe even, "fix" or "feature", that way it's less - Chris
|
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
On Fri, Dec 20, 2019 at 6:15 PM Chris Muller <[hidden email]> wrote:
of a judgement call, like "interesting"... |
Re: The Inbox: PreferenceBrowser-ck.85.mcz
|
|
Hi all!
@frank
> Chris wants a clean history with _meaningful_ chunks of changes. > Other people want commits to be discrete/isolated changes, where "fixing typos" is one kind of change. (*)
> Everyone wants an efficient version control system.
>
> Also: code is easy to change, while people are very hard to change.
Great analysis! :-)
> ... "minor edit" flag ...
Sounds interesting to me, +1!
@Chris
> Your example has nothing to do with scaling. There's no "time-limit" for committing. All that matters is, either the cumulative changes you have waiting on a package have exceeded a threshold of "meaningful" or they haven't. A single one character
change to a literal isn't meaningful enough, no matter how long ago it was done. And, I don't buy that there aren't plenty more improvements to be made, like comments and categorizations, within the same package, which could be committed a "fix pack".
Of course, there may be plenty more improvements to make, but I dispute that I or any other occasional committer will come across these other improvements in the near future.
I like the idea that "every small step counts" which allows everyone to contribute a tiny improvement to any system, without the need to understand or to read the whole project. If I look once in my life into the BitBlt class and find a typo in the class
comment, why shouldn't I fix it?
> Interesting. Something like that could be helpful. Maybe even, "fix" or "feature", that way it's less
We could add something like a simple drop-down menu to the save version dialog for choosing an appropriate category. But we should be careful not to make the committing process too complicated by requiring everyone to fill in a long form :)
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Samstag, 21. Dezember 2019 01:18:40 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: PreferenceBrowser-ck.85.mcz On Fri, Dec 20, 2019 at 6:15 PM Chris Muller <[hidden email]> wrote:
of a judgement call, like "interesting"...
Carpe Squeak!
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |