4.1 release tasks
Locked
123
123
 
|
>>>>> "Ken" == Ken G Brown <[hidden email]> writes:
Ken> * I created the blog, not as my private blog, but as something the members of the SOB could easily use via the posting email address. You presumed that we could not post to board.squeak.org trivially. You presumed wrong. All of the current SOB can put a post up there within 15 seconds. Ken> I find the personal attacks, derogatory accusations, quality of responses in general with respect to my creation of the blog for the SOB to use, to be very, very disappointing. You started with a false assumption, and when called false, you dug in, rather than accepting the truth. It's not a personal attack when people point out you are spouting falsehoods. Move on. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
|
|
In reply to this post by Ken G. Brown
On 20.03.2010, at 02:27, Ken G. Brown wrote:
> > At 4:24 PM -0700 3/19/10, Colin Putney apparently wrote: >> On 2010-03-19, at 12:46 PM, Ken G. Brown wrote: >> >>> Thank you also for your opinion. >>> >>> It is not clear to me who on the board has the authority to ask me to take it down? >>> All 7 perhaps unanimously like you mentioned was the signing requirement for the SOB? Or a majority 4/7? A designated member in charge of communications? It is unclear to me who even can speak on behalf of the SOB. >> >> So, because there's no documentation about who can speak for the board, you claim that right for yourself, and refuse to recognize the right of actual board members to do so? > > At the time I did not know whether everyone on the SOB felt the same way or whether it was just the vocal 3/7 minority. It seemed to me at the start that the SOB in general would welcome an easy way to post stuff to a FAQ type place. Boy was I wrong. > I suppose I was logically assuming that a majority would be the way it might work, perhaps not. Perhaps everyone on the SOB speaks individually on behalf of the SOB. > > Ken G. Brown Unless specifically marked, no-one is speaking on behalf of the SOB. Distrusting governments is (unfortunately) not a bad idea nowadays, but you are also disrespecting us as individuals. It's not that you need to pay respect *because* someone is on the board. But being elected to the board indicates that the community at large trusts these individuals. By extension, this means you are disrespectful to the community. Time is the most valuable resource a volunteer community has. You are wasting our time. I find that offensive, both as a community member, and even more so as a board member, because the community entrusted us to keep this project going. So, can we please get back to the topic of this thread? Are you actually going to contribute to the release? If you do not want to, can you just leave us alone? - Bert - |
|
On Sat, Mar 20, 2010 at 10:49, Bert Freudenberg <[hidden email]> wrote:
So, can we please get back to the topic of this thread? +1 |
|
|
In reply to this post by Bert Freudenberg
On 2010-03-20, at 3:49 AM, Bert Freudenberg <[hidden email]> wrote: > On 20.03.2010, at 02:27, Ken G. Brown wrote: >> >> At 4:24 PM -0700 3/19/10, Colin Putney apparently wrote: >>> On 2010-03-19, at 12:46 PM, Ken G. Brown wrote: >>> >>>> Thank you also for your opinion. >>>> >>>> It is not clear to me who on the board has the authority to ask >>>> me to take it down? >>>> All 7 perhaps unanimously like you mentioned was the signing >>>> requirement for the SOB? Or a majority 4/7? A designated member >>>> in charge of communications? It is unclear to me who even can >>>> speak on behalf of the SOB. >>> >>> So, because there's no documentation about who can speak for the >>> board, you claim that right for yourself, and refuse to recognize >>> the right of actual board members to do so? >> >> At the time I did not know whether everyone on the SOB felt the >> same way or whether it was just the vocal 3/7 minority. It seemed >> to me at the start that the SOB in general would welcome an easy >> way to post stuff to a FAQ type place. Boy was I wrong. >> I suppose I was logically assuming that a majority would be the way >> it might work, perhaps not. Perhaps everyone on the SOB speaks >> individually on behalf of the SOB. >> >> Ken G. Brown > > Unless specifically marked, no-one is speaking on behalf of the SOB. > > Distrusting governments is (unfortunately) not a bad idea nowadays, > but you are also disrespecting us as individuals. It's not that you > need to pay respect *because* someone is on the board. But being > elected to the board indicates that the community at large trusts > these individuals. By extension, this means you are disrespectful to > the community. > > Time is the most valuable resource a volunteer community has. You > are wasting our time. I find that offensive, both as a community > member, and even more so as a board member, because the community > entrusted us to keep this project going. > > So, can we please get back to the topic of this thread? Are you > actually going to contribute to the release? If you do not want to, > can you just leave us alone? > > - Bert - > I have found the treatment I have received with respect to this matter to be offensive as well. I too have better things I could be doing. Ken G. Brown |
|
|
In reply to this post by Levente Uzonyi-2
class | selector | result
--------------------------+--------------------------------+---------
BitBltTest | testAllAlphasRgbAdd | failure BitBltTest | testAllAlphasRgbMax | failure BitBltTest | testAllAlphasRgbMin | failure BitBltTest | testAllAlphasRgbMinInvert | failure BitBltTest | testAllAlphasRgbMul | failure BitBltTest | testAllAlphasRgbSub | failure > The above 6 are vm bugs, fixed in newer vms. So I guess it is ok to make them expected failures until the new VMs are out. ClosureCompilerTest | testDebuggerTempAccess | failure ClosureCompilerTest | testInjectIntoDecompilations | failure ClosureCompilerTest | testInjectIntoDecompiledDebugs | failure DebuggerUnwindBug | testUnwindDebuggerWithStep | failure > AFAIK the above four are known bugs, Eliot has the fixes, the have to be integrated sometime. LocaleTest | testIsFontAvailable | failure > This is font dependent. We should probably add it to expected failures if the default font is not Accuny. MCChangeNotificationTest | testCoreMethodModified | failure > That one is related to system change notifications. If you run this test alone, it passes. True. How do we handle this? PackageDependencyTest | testST80 | failure PackageDependencyTest | testSUnit | failure > These were fixed earlier. I still get the above SMDependencyTest | test2 | error > VM bug, will be fixed in the next vm release. So it's also ok to make it an expected error WorldStateTest | testDeferredUIQueueTimeout | failure > Never seen this failing on windows. This only fails for me when doing all tests ... Alex |
|
|
Note that the new VMs for 4.1 are on the way, so we will have to revert
the vm related expected failures, or make them VM(Maker) version dependent. Levente On Sun, 21 Mar 2010, Alexander Lazarević wrote: > class | selector | result > --------------------------+--------------------------------+--------- > BitBltTest | testAllAlphasRgbAdd | failure > BitBltTest | testAllAlphasRgbMax | failure > BitBltTest | testAllAlphasRgbMin | failure > BitBltTest | testAllAlphasRgbMinInvert | failure > BitBltTest | testAllAlphasRgbMul | failure > BitBltTest | testAllAlphasRgbSub | failure > >> The above 6 are vm bugs, fixed in newer vms. > > So I guess it is ok to make them expected failures until the new VMs are > out. > > ClosureCompilerTest | testDebuggerTempAccess | failure > ClosureCompilerTest | testInjectIntoDecompilations | failure > ClosureCompilerTest | testInjectIntoDecompiledDebugs | failure > DebuggerUnwindBug | testUnwindDebuggerWithStep | failure > >> AFAIK the above four are known bugs, Eliot has the fixes, the have to be > integrated sometime. > > LocaleTest | testIsFontAvailable | failure > >> This is font dependent. We should probably add it to expected failures if > the default font is not Accuny. > > MCChangeNotificationTest | testCoreMethodModified | failure > >> That one is related to system change notifications. If you run this test > alone, it passes. > > True. How do we handle this? > > PackageDependencyTest | testST80 | failure > PackageDependencyTest | testSUnit | failure > >> These were fixed earlier. > > I still get the above > > SMDependencyTest | test2 | error > >> VM bug, will be fixed in the next vm release. > > So it's also ok to make it an expected error > > WorldStateTest | testDeferredUIQueueTimeout | failure > >> Never seen this failing on windows. > > This only fails for me when doing all tests ... > > Alex > |
|
|
2010/3/21 Levente Uzonyi <[hidden email]> so we will have to revert the vm related expected failures That shouldn't be a problem, because they will then show up as unexpected passes Alex |
|
|
But true, we still have to remember to change the tests after a VM update.
On Sun, Mar 21, 2010 at 13:31, Alexander Lazarević <[hidden email]> wrote:
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |