[Election] ...is soon upon us! Last day info
Locked
[Election] ...is soon upon us! Last day info
 
|
Nicolas Cellier wrote:
>Then I want you to play a little game: >take the exact Installer script that installed my mantis patches over >3.10, apply it to latest trunk, Cuis and Pharo, and report how it >worked. Nicolas, forget to play such games. I already requested Keith to play such a game and demonstrate his technology to me (see bottom of [1]). The answer was totally unsatisfying (see bottom of [2]). IMHO it will never succeed as long as the original author is not able to demonstrate or even explain in a way so we could really follow. Maybe Ken can ... Bye T. [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003871.html [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003875.html -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 |
|
|
On 10 Mar 2010, at 20:18, Torsten Bergmann wrote: > Nicolas Cellier wrote: >> Then I want you to play a little game: >> take the exact Installer script that installed my mantis patches over >> 3.10, apply it to latest trunk, Cuis and Pharo, and report how it >> worked. Why would you even expect that to work without human intervention? If the person who wants to load the fixes into pharo marks/tags the ones he tests as working in pharo, then those marked as working in pharo would load. If that is too difficult then you use a task to define a fix in which the task knows its dependencies. For example in my Magma load into Cuis, looks directly to see if the image already has Mutex loaded, if it doesn't then it loads it. Keith |
|
|
In reply to this post by Torsten Bergmann
Keith |
Re: [Election] ...is soon upon us! Last day info
|
|
In reply to this post by keith1y
2010/3/10 keith <[hidden email]>:
> > On 10 Mar 2010, at 20:18, Torsten Bergmann wrote: > >> Nicolas Cellier wrote: >>> >>> Then I want you to play a little game: >>> take the exact Installer script that installed my mantis patches over >>> 3.10, apply it to latest trunk, Cuis and Pharo, and report how it >>> worked. > > Why would you even expect that to work without human intervention? > > If the person who wants to load the fixes into pharo marks/tags the ones he > tests as working in pharo, then those marked as working in pharo would load. > > If that is too difficult then you use a task to define a fix in which the > task knows its dependencies. > Yes, Keith, that's too difficult, because you have to know that patchA works in Pharo 11231, Pharo 11232 etc... Then you also have to know if patchB works in Pharo 11231+patchA, Pharo 11232+patchB etc... Try the combinations of trunk patches and come back with real facts. Nicolas > For example in my Magma load into Cuis, looks directly to see if the image > already has Mutex loaded, if it doesn't then it loads it. > > Keith > > |
Re: [Election] ...is soon upon us! Last day info
|
|
In reply to this post by Torsten Bergmann
2010/3/10 Torsten Bergmann <[hidden email]>:
> Nicolas Cellier wrote: >>Then I want you to play a little game: >>take the exact Installer script that installed my mantis patches over >>3.10, apply it to latest trunk, Cuis and Pharo, and report how it >>worked. > > Nicolas, > > forget to play such games. I already requested Keith to play such a game > and demonstrate his technology to me (see bottom of [1]). The answer was > totally unsatisfying (see bottom of [2]). > > IMHO it will never succeed as long as the original author is not > able to demonstrate or even explain in a way so we could really follow. > Maybe Ken can ... > > Bye > T. > Be sure, I won't play myself, I know very well the result. That's just to stop false assertions to be repeated over and over again. The patches have a limited lifetime. Code lives and dies. It dies because it has good reasons to. Unless you think trunk evolutions were all gratuitous and we should better revert ? One easy demonstration would be to traverse trunk MC repository and count how many times each method were changed... For external packages, i want to believe the Installer scripts works well. But not for trunk... It could work in a continuous integration scheme but then it's not really far from trunk process, just with less convenient tools for multi-developper. And don't tell cross fork patches come for free. Keith is right when he says trunk dev. model is not easy to duplicate. He is right because changes span over several packages, and gathering information is tedious. Maybe Pharo SLICE policy improve the model a bit : - publish a bug report - make a fix in Pharo - create a SLICE package, let it depend on all dirty packages, publish the SLICE. If harvesters wait too long, then the SLICE is obsolete and can conflict with other changes. MC merge feature helps in this case. Which Installer tool does ? I'm not a MC-fanatic, it has some weaknesses. The worst thing regarding MC is whenever class and methods move into another package, so it certainly must be improved. But I don't buy changeSets, I already know the limits too well. Nicolas > [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003871.html > [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003875.html > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > |
Re: [Election] ...is soon upon us! Last day info
|
|
On 10 March 2010 23:20, Nicolas Cellier
<[hidden email]> wrote: > 2010/3/10 Torsten Bergmann <[hidden email]>: >> Nicolas Cellier wrote: >>>Then I want you to play a little game: >>>take the exact Installer script that installed my mantis patches over >>>3.10, apply it to latest trunk, Cuis and Pharo, and report how it >>>worked. >> >> Nicolas, >> >> forget to play such games. I already requested Keith to play such a game >> and demonstrate his technology to me (see bottom of [1]). The answer was >> totally unsatisfying (see bottom of [2]). >> >> IMHO it will never succeed as long as the original author is not >> able to demonstrate or even explain in a way so we could really follow. >> Maybe Ken can ... >> >> Bye >> T. >> > > Be sure, I won't play myself, I know very well the result. > That's just to stop false assertions to be repeated over and over again. > The patches have a limited lifetime. Code lives and dies. > It dies because it has good reasons to. > Unless you think trunk evolutions were all gratuitous and we should > better revert ? > > One easy demonstration would be to traverse trunk MC repository and > count how many times each method were changed... > > For external packages, i want to believe the Installer scripts works > well. But not for trunk... > It could work in a continuous integration scheme but then it's not > really far from trunk process, just with less convenient tools for > multi-developper. > And don't tell cross fork patches come for free. > > Keith is right when he says trunk dev. model is not easy to duplicate. > He is right because changes span over several packages, and gathering > information is tedious. > Maybe Pharo SLICE policy improve the model a bit : > - publish a bug report > - make a fix in Pharo > - create a SLICE package, let it depend on all dirty packages, publish > the SLICE. > If harvesters wait too long, then the SLICE is obsolete and can > conflict with other changes. > MC merge feature helps in this case. Which Installer tool does ? > > I'm not a MC-fanatic, it has some weaknesses. > The worst thing regarding MC is whenever class and methods move into > another package, so it certainly must be improved. > But I don't buy changeSets, I already know the limits too well. > > Nicolas > >> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003871.html >> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003875.html >> -- >> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Nicolas Cellier
Why are you trying to patch a moving target, with fixed patches. Of course if the target moves the patches have to move with the target, in the lower layers. Higher architectural levels should be isolated from such changes. I am saying that you need to patch a fixed target with fixed patches in a prescribed order if an order is needed, spend time getting it working, and release a new fixed target. The result will be release of images at fixed points A and B, with a prescribed detailed process of exactly how you got from release A to release B. That is a useful and desirable result because it captures the knowledge as well as producing a new image. Capturing the knowledge is the important enabler for cross fork working, and for maintaining the map of load-able packages across forks. Secondly you divide the target vertically into modules and subsystems, so that the problem is split up among different teams/individual experts. Thirdly you divide the target horizontally into architectural layers, and within each layer you can divide the modifications into a load order and group them according their function for clarity and knowledge capture. Fourthly you release different versions of the image for different purposes, e.g. "base-dev" as the starting point for most kernel innovators such as yourself. "~kph/stable" for the intregration and ~nice/stable for your completed innovationsdemonstration of my chosen completed innovations, and "~whoever/unstable" for the rest. = In our old bob process this was organised as a set of named tasks, in an order calculated from implicit and explicit dependencies. So the essential fixes task was loaded first, followed by package upgrades etc and at the end deprecated methods were removed, the verision number set and the image cleanedUp and saved. My new process "grow", we forget using dependencies and instead use a semi-rigid framework which gives us a fixed load order. We split the image vertically by defining slices of Kernel (e.g. Mutex is a discrete slice), and System is divided into packages. Horizontally we have up to 9 layers, from 0 to 9, in which 0-3 would be for basic core/kernel image use, and for example, seaside would be loaded at somewhere around level 4/5. Within each layer (particularly the lower layers) there are 12/13 ordered load phases. So at layer 0, the lowest level in the kernel, the first phase is the bootstrap phase. The bootstrap always loads the essential code loading tools, and absolutely essential fixes in a primitive manner in the image commandline startUp script. This is essential because the code loading tools can never reliably load the code loading tools. The phases are applied in alphabetical order, in layer 0 first, then layer 1 then layer 2 etc. 1 #bootstrap - load code loading tools (layer 0 only) 2 #fixes - fix actual broken stuff 3 #installs - install of packaged code slices 4 #moves - refactorings 5 #newapi - additions to the base api 6 #packages - install of packaged code packages (e.g. MCZ) 7 #patches - patches to packages above for this context. 8 #parity - fixes providing code parity between forks, that might be needed by the package. 9 #preferences - code which sets things up the way you like it 10 #tests - load tests from a package 11 #tidy - (re)organise things to your preference 12 #unload - remove things 13 #zed - a finalization phase. So with an architecture in place you use it to define roles and responsibilities, and boundaries to make the problem manageable. Sure I agree, in layer 0, things will need to be hand crafted and bespoke to that image. However even within this layer you can see what is a fix for a bug (#fix) what is a refactoring (#move) that should not change functionality, and what is an attempt to provide a #newapi or api parity between forks. If you are writing a bug fix, you can address that fix to the virtually untouched release image by publishing it as a <project: 'MyFixes' level: 0 series: #fix item: 1> e.g. If you are adding core #newapi calls, you know you are doing so to the basic image before any add on packages are loaded at this level. But by the time you get to layer 3, there are three layers of stuff under you that can provide your packages some commonalty of api across forks. "Grease" would be welcome at layer 2 / 3. In practice, we want to deliver a base image for people to use, this image is called "base-dev", and it consists of two main parts, the fork specific part, and the common part. base-dev/Kernel & base-common/Kernel-common So the bootstrap script fed to the starting image, can be made up of code that is either bespoke to a fork, or common to all forks, or both. There is a cuis/base-dev, a squeak/base-dev and a pharo/base-dev. The bootstrap for all three is assembled from code that is common to all three images: grow/base-common/Kernel-common/#0--bootstrap and code that is specific to all three images cuis/base-dev/Kernel/#0--bootstrap squeak/base-dev/Kernel/#0--bootstrap pharo/base-dev/Kernel/#0--bootstrap So right from the initial bootstrap script, we have common code loading tools across all forks, and we are free to innovate those tools in any way we wish. We also have one of the first fixes also included in the bootstrap is the new SmalltalkIMage/Smalltalk dividing scheme - #globals #commandLine #vm #organization #query #changes etc. base-dev provides enough commonality for the import and export code to work supporting the same development process on all forks. Keith |
Re: [Election] ...is soon upon us! Last day info
|
|
2010/3/11 keith <[hidden email]>:
> > > Yes, Keith, that's too difficult, because you have to know that patchA > works in Pharo 11231, Pharo 11232 etc... > Then you also have to know if patchB works in Pharo 11231+patchA, > Pharo 11232+patchB etc... > Try the combinations of trunk patches and come back with real facts. > > Hi Nicolas, > Why are you trying to patch a moving target, with fixed patches. Of course > if the target moves the patches have to move with the target, in the lower > layers. Higher architectural levels should be isolated from such changes. > I am saying that you need to patch a fixed target with fixed patches in a > prescribed order if an order is needed, spend time getting it working, and > release a new fixed target. The result will be release of images at fixed > points A and B, with a prescribed detailed process of exactly how you got > from release A to release B. That is a useful and desirable result because > it captures the knowledge as well as producing a new image. Capturing the > knowledge is the important enabler for cross fork working, and for > maintaining the map of load-able packages across forks. Agree That's more or less what happens in trunk. It goes from fixed point to fixed point (each MCM is a fixed point as Levente said). The difference is about documenting the changes. It's a mix of squeak-dev mail exchanges and MC package comments. That's what makes trunk development very efficient in trunk (e.g. compared to Pharo where you first open an issue and then publish in inbox and wait for pair review). But of course harder for cousin forks. I agree, other forks are forced to pay attention to squeak trunk development which costs. But if the goal is to cherry pick, anyway, the changes are to be re-analysed and re-done since fixedPoints in lower levels probably won't be compatible. Unless the lower levels are shared (like composing different images combination from a common kernel), but that's not the current model. > Secondly you divide the target vertically into modules and subsystems, so > that the problem is split up among different teams/individual experts. > Thirdly you divide the target horizontally into architectural layers, and > within each layer you can divide the modifications into a load order and > group them according their function for clarity and knowledge capture. > Fourthly you release different versions of the image for different purposes, > e.g. "base-dev" as the starting point for most kernel innovators such as > yourself. "~kph/stable" for the intregration and ~nice/stable for your > completed innovationsdemonstration of my chosen completed innovations, and > "~whoever/unstable" for the rest. > = > In our old bob process this was organised as a set of named tasks, in an > order calculated from implicit and explicit dependencies. So the essential > fixes task was loaded first, followed by package upgrades etc and at the end > deprecated methods were removed, the verision number set and the image > cleanedUp and saved. > My new process "grow", we forget using dependencies and instead use a > semi-rigid framework which gives us a fixed load order. > We split the image vertically by defining slices of Kernel (e.g. Mutex is a > discrete slice), and System is divided into packages. > Horizontally we have up to 9 layers, from 0 to 9, in which 0-3 would be for > basic core/kernel image use, and for example, seaside would be loaded at > somewhere around level 4/5. > Within each layer (particularly the lower layers) there are 12/13 ordered > load phases. So at layer 0, the lowest level in the kernel, the first phase > is the bootstrap phase. > The bootstrap always loads the essential code loading tools, and absolutely > essential fixes in a primitive manner in the image commandline startUp > script. This is essential because the code loading tools can never reliably > load the code loading tools. Maybe a clone of the loading tools could. > The phases are applied in alphabetical order, in layer 0 first, then layer 1 > then layer 2 etc. > 1 #bootstrap - load code loading tools (layer 0 only) > 2 #fixes - fix actual broken stuff > 3 #installs - install of packaged code slices > 4 #moves - refactorings > 5 #newapi - additions to the base api > 6 #packages - install of packaged code packages (e.g. MCZ) > 7 #patches - patches to packages above for this context. > 8 #parity - fixes providing code parity between forks, that might be needed > by the package. > 9 #preferences - code which sets things up the way you like it > 10 #tests - load tests from a package > 11 #tidy - (re)organise things to your preference > 12 #unload - remove things > 13 #zed - a finalization phase. > So with an architecture in place you use it to define roles and > responsibilities, and boundaries to make the problem manageable. Sure I > agree, in layer 0, things will need to be hand crafted and bespoke to that > image. However even within this layer you can see what is a fix for a bug > (#fix) what is a refactoring (#move) that should not change functionality, > and what is an attempt to provide a #newapi or api parity between forks. > If you are writing a bug fix, you can address that fix to the virtually > untouched release image by publishing it as a <project: 'MyFixes' level: 0 > series: #fix item: 1> e.g. > If you are adding core #newapi calls, you know you are doing so to the basic > image before any add on packages are loaded at this level. > But by the time you get to layer 3, there are three layers of stuff under > you that can provide your packages some commonalty of api across forks. > "Grease" would be welcome at layer 2 / 3. > In practice, we want to deliver a base image for people to use, this image > is called "base-dev", and it consists of two main parts, the fork specific > part, and the common part. > base-dev/Kernel & > base-common/Kernel-common > So the bootstrap script fed to the starting image, can be made up of code > that is either bespoke to a fork, or common to all forks, or both. > There is a cuis/base-dev, a squeak/base-dev and a pharo/base-dev. The > bootstrap for all three is assembled from code that is common to all three > images: > grow/base-common/Kernel-common/#0--bootstrap > and code that is specific to all three images > cuis/base-dev/Kernel/#0--bootstrap > squeak/base-dev/Kernel/#0--bootstrap > pharo/base-dev/Kernel/#0--bootstrap What about concurrent changes between contributors ? Say I changed a private method A that Levente removes. That's where MC shines. > So right from the initial bootstrap script, we have common code loading > tools across all forks, and we are free to innovate those tools in any way > we wish. We also have one of the first fixes also included in the bootstrap > is the new SmalltalkIMage/Smalltalk dividing scheme - #globals #commandLine > #vm #organization #query #changes etc. > base-dev provides enough commonality for the import and export code to work > supporting the same development process on all forks. > Keith > Thanks for taking time to explain your model. The main problem you will face is that you currently don't control the fix point neither of trunk, nor of Pharo, maybe not even of Cuis. The second is to convince squeakers to adopt new model and new tools. Both tasks are very ambitious... Nicolas |
|
|
The cycle consists of... check out slices and packages from the repo, build one or more images, export slices to source, check in code to repo. So you have SCM tools working on the important source files to tell you what has changed or what has conflicted. It is not as good at diffing mcz packages since they are zip files, but it does ok on a method level in an st file. Secondly you can take someone else's image, import the slice definitions to it, and the Export doCheck will tell you what has changed in their image relative to the slices exported from yours. Keith |
|
|
In reply to this post by Nicolas Cellier
>>
>> The bootstrap always loads the essential code loading tools, and >> absolutely >> essential fixes in a primitive manner in the image commandline >> startUp >> script. This is essential because the code loading tools can never >> reliably >> load the code loading tools. > > Maybe a clone of the loading tools could. Yes indeed, we would like to have a poor-mans namespace solution of some kind even for legacy images. This can be done via grep/awk on the source file easily enough. > Thanks for taking time to explain your model. > The main problem you will face is that you currently don't control the > fix point neither of trunk, nor of Pharo, maybe not even of Cuis. But I don't care about building stuff in pharo or trunk. I am only ripping stuff out of them, and tracking changes there, so I only need my tools to load that is all, just 3/4 significant classes. Cuis on the other hand uses a nice simple single update stream that I can see. (just like Edgar is wishing for again) Juan has promised to stick to the kernel of the image and not be a control freak about the whole thing, he is not imposing any tools on me and he is not putting up any barriers to what I can do in the image. Best of all he is not the bottleneck in the process. I dont have to persuade him to incorporate my fixes, because he is happy without them, and I am happy with them. > The second is to convince squeakers to adopt new model and new tools. I don't want to convince squeakers, all I want is control of the image back to do a job. However, anyone who does join us, on [hidden email] , or in irc #cuis I can promise you control of your own image, and I can promise you you can fork as much as you need to, but if you use this toolset you will not get left behind because the forum and tools for exchange of innovations between forks is in place. No image ever gets "released" and given to you to cope with. Rather completed stable features get released. You build the image you want by picking the stable features you want. No image you build ever stops being supported, although I use cuis as a starting point, you can pick your own starting point. Every innovation will be planned, documented, crafted and published separately for integration. not a bad start for a manifesto. Keith |
Re: [Election] ...is soon upon us! Last day info
|
|
2010/3/11 keith <[hidden email]>:
> However, anyone who does join us, on [hidden email] , or > in irc #cuis I can promise you control of your own image, and I can promise > you you can fork as much as you need to, but if you use this toolset you > will not get left behind because the forum and tools for exchange of > innovations between forks is in place. > > No image ever gets "released" and given to you to cope with. Rather > completed stable features get released. You build the image you want by > picking the stable features you want. > > No image you build ever stops being supported, although I use cuis as a > starting point, you can pick your own starting point. Every innovation will > be planned, documented, crafted and published separately for integration. > > not a bad start for a manifesto. > > Keith You are promising a lot for someone not into politics. You are also taking a lot of time talking about other things that are unrelated to Cuis. Not that any of these are wrong. It just makes me think a bit... and I have a question for you. Why didn't you run for the Board? You have a clear picture of what you want and you are no short of words about the subject that passionate you. This is a good thing. Some people who ran for the board did not have had as much to say as you do. I wonder why you did not take your chance to "straighten up" things. This would also have been an incredible opportunity for you to gauge the interest of your peers and readjust yourself if otherwise failing. Now, you may say very harsh things about the board and perhaps they are all true. History has however taught us that every time one of two parties retracted from the adversity in spite of what they truly believed, the other party came to absolute power and bad things happened. Ian. -- http://mecenia.blogspot.com/ |
Re: [Election] ...is soon upon us! Last day info
|
|
In reply to this post by keith1y
On 3/11/10 9:30 PM, "keith" <[hidden email]> wrote: > Yes indeed, we would like to have a poor-mans namespace solution of > some kind even for legacy images. This can be done via grep/awk on the > source file easily enough. Could ellaborate more ? This is a very important as in the end we need a kernel .image , like Pavel old for 3.7. He never go for having a unix console (Terminal in os X), so if you have some here , like to know. A very distant LinXqueak is my last goal... Edgar |
|
|
In reply to this post by Ian Trudel-2
Because it would not be ethical. The purpose of the board is to represent and to liaise and co-ordinate with the community. In other words, a world without the board, is supposed to made better and nicer place to be in by the fact that the board is there. This is because the board is present to ensure that the community is represented and people and ideas are treated fairly. In a world without the board "charisma", cliques, and historical founders, simply override. The board is not a management committee, which you appoint in order to get things done within a specific remit, like putting on an event, or producing a release. Our board is there for oversight and co-ordination within the community. So you would expect them to co-ordinate and oversee, not to dictate. The fact that you suggest that I run for the board to represent my ideas, tells me several things. Firstly it tells me that the board is not doing its job, because apparently I now need to be elected to have a voice, and to get my way. When in actual fact the board is supposed to be there in order to give me a voice, since the board represents and liaises with the community and that includes me. So I should be able to trust the board, that if an issue comes up that concerns me, I will not be excluded form the discussion, and I will be invited to participate. For example, when this release, "pharo is ahead of us" debate that panicked the board last year occurred, I was actually on holiday. (In actual fact we were way ahead of pharo in many respects at the time, but that is another issue) The fact that I didn't engage with this debate, because I felt it was irrelevant and I was on holiday and the board had already supported my positon, after giving my proposal due consideration, is something I should have been able to rely on. The board is supposed to provide more stability to the community not less. You see if an issue comes up, such as how to sort out the next release, for example. It is the boards job to gather all that are concerned and to make sure that no voice is left unheard, and to make a considered decision to the satisfaction of all concerned. So, if I was to get elected on the basis of wanting to represent my own interests, and my own ideas.I would not even vote for myself. Keith |
Re: [Election] ...is soon upon us! Last day info
|
|
2010/3/12 keith <[hidden email]>:
> > Why didn't you run for the Board? > Because it would not be ethical. > The board is not a management committee, which you appoint in order to get > things done within a specific remit, like putting on an event, or producing > a release. Our board is there for oversight and co-ordination within the > community. So you would expect them to co-ordinate and oversee, not to > dictate. Yes, you're right. I have simply not seen the board exceed the scope of their mandate to the point of dictating. There are however “leading by example” where some of them have produced work that you may not agree with and pushed it in the trunk. While it may not represent anything you want, it has inspired others. My point is that I've heard many times that a given person was a dictator, whether it is in a community or a company. Most often it is out of frustration than factual. To my own experience, leading people is difficult and even the soft-soft approach will turn employees to dis a boss. Trying to please everybody? Undecided. Soft-soft approach? Lack of leadership. Dedicated? Dictator. And so on. > The fact that you suggest that I run for the board to represent my ideas, > tells me several things. Firstly it tells me that the board is not doing its > job, because apparently I now need to be elected to have a voice, and to get > my way. When in actual fact the board is supposed to be there in order to > give me a voice, since the board represents and liaises with the community > and that includes me. You do have a voice. You get a huge load of replies each time you write an email here. I don't get that. It's even more interesting to see you have so much attention on Squeak mailing list, on Squeak related matter, when your interest is in Cuis. Perhaps, you feel unheard because your way do not prevail? A voice and getting one's way are two different things. There is a fundamental social concept that one has to “sell” his or her ideas to others in order to obtain some form of collaboration. Whether a person is a member of a community or an employee in a company, he or she has to convince others that his or her ideas are the best suited for a given situation. Even a big boss in a big company has to convince his or her employees if he or she wants full collaboration (rather than coerced by authority); even the most flexible employees can have a strong resistance to change. Now, I don't make the social rules. You are not forced to follow any of them. The outcome is however always the same: one becomes an outcast. Is it fair? No. It's only human nature. In a nutshell, don't expect anybody to drag you and put you up on a stadium because you've had an idea and did a huge amount of work on it: you've got to continuously work for peer approval. > So I should be able to trust the board, that if an issue comes up that > concerns me, I will not be excluded form the discussion, and I will be > invited to participate. For example, when this release, "pharo is ahead of > us" debate that panicked the board last year occurred, I was actually on > holiday. (In actual fact we were way ahead of pharo in many respects at the > time, but that is another issue) The fact that I didn't engage with this > debate, because I felt it was irrelevant and I was on holiday and the board > had already supported my positon, after giving my proposal due > consideration, is something I should have been able to rely on. The board is > supposed to provide more stability to the community not less. The world does not revolve around you, Keith. An open source project should keep going even though some people are busy, on holidays, not interested in a certain subject, etc. That's how such projects keep the momentum and become successful (or don't die forgotten in a ditch). You may be offended that they did not wait for you but you've just admitted you thought it was an irrelevant discussion. It appeared this discussion was more important than you have anticipated and you've made a mistake not being there. Don't blame others for this one, you said that it was irrelevant. ;) > You see if an issue comes up, such as how to sort out the next release, for > example. It is the boards job to gather all that are concerned and to make > sure that no voice is left unheard, and to make a considered decision to the > satisfaction of all concerned. I agree to some extent. It's sometimes absolutely impossible to bring satisfaction to every party involved. Correct me if I am wrong, I paraphrase, you say: “I presented an idea, worked hard on it, you must agree to my satisfaction.” You leave absolutely no room for the possibility that your satisfaction may be to the dissatisfaction of others. Who's inflexible here? Do you work at home? I believe you are self employed. Everything you tell me makes me think that you don't work in an office nor have your own team. You are idealizing what social interaction should be without any consideration for the human factor. Humans are humans, true to their nature. Working in group also means drama, unfairness, being not heard, and the list goes on. It may also mean that if one idea of yours does not work in a community, even a good one, it should be readjusted, (or) should be keep to yourself or you should move on. > So, if I was to get elected on the basis of wanting to represent my own > interests, and my own ideas.I would not even vote for myself. I respect your position and it's good that you don't go for something that you believed to be unethical. My perception of you is that you are passionate, devoted and a hard worker. I am sure that you could have a major turn about in this community if you would want to change your way a little bit. People are willing to communicate with you, to hear you, to like you, but you are sometimes inflexible. You don't need to be a rock star and overly charismatic to make people follow your way. It's however ridiculous to think that no social effort is required to make your ideas successful. Thanks for your insight, Keith. Ian. -- http://mecenia.blogspot.com/ |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |