[squeak-dev] http://source.squeak.org/trunk is now at 3.10.2
Locked
12
12
[squeak-dev] Re: http://source.squeak.org/trunk is now at 3.10.2
 
|
On Sat, 04 Jul 2009 13:29:17 +0200, Keith Hodges wrote:
> Klaus D. Witzel wrote: >> On Sat, 04 Jul 2009 12:14:14 +0200, Keith Hodges wrote: >> >> ... >>>> the source.squeak.org model is centered "around" small units, packages >>>> (the thing supported by the MC tool). So a handful of developers can >>>> and do work with/in the same package, usually without disturbing other >>>> teams. >>>> >>> Ok lets take an example.... I have a package "Logging" one possible >>> way >>> forward is to replace every instance of Transcript show: with a call to >>> the logging framework. >> >> There can only be one package which contains the implementation for >> Transcript, so just go ahead with changing that implementation. > Are you kidding me? Get serious, Keith. You're hijacking my answer to Ian, which has nothing to do with the troubles you have with SOB. So just get serious. > Look for senders of #show: I think you will find more than one caller I'm not interested in your senders of #show: since that doesn't tell us anything. Would you disclose what your senders of #show: is about? And you cut away my question to you. If I do not see it again, you'll not see any other reponse. /Klaus > Keith > |
|
|
I will start again...
My point is that any worthwhile refactoring project will probably transcend the majority of packages, both in the kernel and without. Example 1. Replacing FileDirectory - will effect a high percentage of packages in the kernel and virtually every package in SqueakMap will need to be ported. Example 2. Namespaces - will effect a proportion of kernel packages and MC tools, compiler etc. Example 3. Replacing _ with := is not a project that is rescricted to one repository. Eaxmple 4. Logging If you have a headless image, you might want to use a logging device instead of Transcript. So every place in the kernel where people have put Transcript show: in order to fulfil the role of "logging" would need to be replaced with a call to the logging dispatch framework. i.e. "Transcript show: someValue" becomes something like "self log info kernel someValue: someValue." == So here we have 4 projects that could be undertaken to improve squeak. What do they have in common... 1. All of these projects could be applied to any existing squeak image, cobalt, croquet, gjallar, pharo, 3.7 - 3.10 etc. So the potential target audience is not just 3.11 users (who only represent a minority of the squeak community). 1. None of them would be doable using the package maintenance model that you are proposing. It is not true to say that one team can work without bumping into another team as you propose. 2. You wouldnt be able to undertake any of the above projects concurrently within a single repository, without people falling over each other, and or the projects becoming inextricably linked. 3. The knowledge capture as to how to perform each project gets confused with the activities of the other projects. Therefore this knowledge is not useful to anyone other than the developers of that one image. If Cobalt wants to use Logging too (and they already are doing so) they would have to repeat all the work from scratch they would not be able to reuse any of the knowledge gained from doing it in 3.10. Why? because the the process of performing the refactoring was done against a moving target, and it is not possible to say... You applied this process to image 3.10 and I want to apply it to my image which is derived from 3.8, if I analyse the differences between 3.8 and 3.10, I should be able to take your delta (DS/CS) and apply it to my image. Keith |
Re: [squeak-dev] Re: http://source.squeak.org/trunk is now at 3.10.2
|
|
On 7/4/09 9:30 AM, "Keith Hodges" <[hidden email]> wrote: > I will start again... > > My point is that any worthwhile refactoring project will probably > transcend the majority of packages, both in the kernel and without. > > Example 1. Replacing FileDirectory - will effect a high percentage of > packages in the kernel and virtually every package in SqueakMap will > need to be ported. > > Example 2. Namespaces - will effect a proportion of kernel packages and > MC tools, compiler etc. > > Example 3. Replacing _ with := is not a project that is rescricted to > one repository. > > Eaxmple 4. Logging > > If you have a headless image, you might want to use a logging device > instead of Transcript. So every place in the kernel where people have > put Transcript show: in order to fulfil the role of "logging" would need > to be replaced with a call to the logging dispatch framework. i.e. > > "Transcript show: someValue" becomes something like "self log info > kernel someValue: someValue." > > == > > So here we have 4 projects that could be undertaken to improve squeak. > What do they have in common... > > 1. All of these projects could be applied to any existing squeak image, > cobalt, croquet, gjallar, pharo, 3.7 - 3.10 etc. So the potential target > audience is not just 3.11 users (who only represent a minority of the > squeak community). > > 1. None of them would be doable using the package maintenance model that > you are proposing. It is not true to say that one team can work without > bumping into another team as you propose. > > 2. You wouldnt be able to undertake any of the above projects > concurrently within a single repository, without people falling over > each other, and or the projects becoming inextricably linked. > > 3. The knowledge capture as to how to perform each project gets confused > with the activities of the other projects. Therefore this knowledge is > not useful to anyone other than the developers of that one image. If > Cobalt wants to use Logging too (and they already are doing so) they > would have to repeat all the work from scratch they would not be able to > reuse any of the knowledge gained from doing it in 3.10. Why? because > the the process of performing the refactoring was done against a moving > target, and it is not possible to say... You applied this process to > image 3.10 and I want to apply it to my image which is derived from 3.8, > if I analyse the differences between 3.8 and 3.10, I should be able to > take your delta (DS/CS) and apply it to my image. > > Keith > Keith you should think in start your own fork as Juan, Pavel, me , and others do. Your way is very different as some of us think is a .image development and the only way is having some .image which people could try , see his number change from 7159 to higher numbers, broken things was fixed and wild ideas show his value. My 5 centavos de peso , what worth almost 1/100 euro. Edgar |
[squeak-dev] Re: http://source.squeak.org/trunk is now at 3.10.2
|
|
Hi Keith,
see also my other message. On Sat, 04 Jul 2009 15:00:09 +0200, Edgar J. De Cleene wrote: > > > > On 7/4/09 9:30 AM, "Keith Hodges" <[hidden email]> wrote: > >> I will start again... >> >> My point is that any worthwhile refactoring project will probably >> transcend the majority of packages, both in the kernel and without. >> >> Example 1. Replacing FileDirectory - will effect a high percentage of >> packages in the kernel and virtually every package in SqueakMap will >> need to be ported. >> >> Example 2. Namespaces - will effect a proportion of kernel packages and >> MC tools, compiler etc. >> >> Example 3. Replacing _ with := is not a project that is rescricted to >> one repository. >> >> Eaxmple 4. Logging >> >> If you have a headless image, you might want to use a logging device >> instead of Transcript. So every place in the kernel where people have >> put Transcript show: in order to fulfil the role of "logging" would need >> to be replaced with a call to the logging dispatch framework. i.e. >> >> "Transcript show: someValue" becomes something like "self log info >> kernel someValue: someValue." >> >> == >> >> So here we have 4 projects that could be undertaken to improve squeak. >> What do they have in common... >> >> 1. All of these projects could be applied to any existing squeak image, >> cobalt, croquet, gjallar, pharo, 3.7 - 3.10 etc. So the potential target >> audience is not just 3.11 users (who only represent a minority of the >> squeak community). >> >> 1. None of them would be doable using the package maintenance model that >> you are proposing. It is not true to say that one team can work without >> bumping into another team as you propose. >> >> 2. You wouldnt be able to undertake any of the above projects >> concurrently within a single repository, without people falling over >> each other, and or the projects becoming inextricably linked. >> >> 3. The knowledge capture as to how to perform each project gets confused >> with the activities of the other projects. Therefore this knowledge is >> not useful to anyone other than the developers of that one image. If >> Cobalt wants to use Logging too (and they already are doing so) they >> would have to repeat all the work from scratch they would not be able to >> reuse any of the knowledge gained from doing it in 3.10. Why? because >> the the process of performing the refactoring was done against a moving >> target, and it is not possible to say... You applied this process to >> image 3.10 and I want to apply it to my image which is derived from 3.8, >> if I analyse the differences between 3.8 and 3.10, I should be able to >> take your delta (DS/CS) and apply it to my image. >> >> Keith >> > > Keith you should think in start your own fork as Juan, Pavel, me , and > others do. Well, be prepared guys: the more forking, the more comparision, the more competition ;) > Your way is very different as some of us think is a .image development > and > the only way is having some .image which people could try , see his > number > change from 7159 to higher numbers, broken things was fixed and wild > ideas > show his value. > > My 5 centavos de peso , what worth almost 1/100 euro. > > Edgar > |
Re[2]: [squeak-dev] Re: http://source.squeak.org/trunk is now at 3.10.2
|
|
In reply to this post by Edgar J. De Cleene
Hello Edgar,
EJDC> Keith you should think in start your own fork as Juan, Pavel, me , and EJDC> others do. EJDC> My 5 centavos de peso , what worth almost 1/100 euro. only problem with this approach is that Keith implements a community process in software. His work is more or less oblivious to the features that are implemented under it. Something along the lines if somebody put a lot of work in rewriting methods for the relicensing process. OTOH all the forks produce an artifact with a set of features defining the difference to Squeak. Most of them en passant bring a new process which is working fine due to the small number of contributors and the good alignment of purpose. Pharo being a bit different in this respect. "Pissing somebody off" or "stepping on somebody's toes" are not describing what happens here. It's simply "undermining authority". The result is as simple, people won't take responsibility. And the board AFAIK explicitly stated they are not here to do the work. Not even team leading. I have seen no criticism in how Keith fulfills his team leadership. Letting him find out in the newspaper (aka SqueakDev) that the process he is implementing has been ditched is a very effective form of publicly undermining authority. This should be resolved gracefully, as such things are harmful to community, especially to one which right now has problems with being a community. One thing to be learned is that a team needs a "communication officer" like Ken provides for the Box admins Team and the board. Actually I envy Keith for being able to handle this with only very few lapses into "being pissed off mode". Best regards, Herbert mailto:[hidden email] |
Re[3]: [squeak-dev] Re: http://source.squeak.org/trunk is now at 3.10.2
|
|
Hi,
HK> "Pissing somebody off" or "stepping on somebody's toes" are not HK> describing what happens here. It's simply "undermining authority". The HK> result is as simple, people won't take responsibility. And the board HK> AFAIK explicitly stated they are not here to do the work. Not even HK> team leading. sorry I didn't see Andreas post before sending this. So there is awareness of the political aspects which is what I wanted to point attention to. -- Best regards, Herbert mailto:[hidden email] |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |