[Election] ...is soon upon us! Last day info

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Election] ...is soon upon us! Last day info

Göran Krampe
Hi all!

Ok, so tonight at 18.00 UTC the actual voting period starts. It goes
like this:

- Around 18.00 UTC tonight you will get an email from the CIVS voting
system with a link in it. You have one week to click on that link and vote.

- If you realize that you never got this email it can be because of mail
problems or that you aren't on the voter list. Send me an email in
either case and I will try to sort it out.

- If you voted last year you are already on the list.

I will accept new voters during the whole voting week! I will also do my
best to fix any issues with ballots gone missing in the SMTP jungle.

regards, Göran


Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

keith1y
> Hi all!
>
> Ok, so tonight at 18.00 UTC the actual voting period starts. It goes  
> like this:
>
> - Around 18.00 UTC tonight you will get an email from the CIVS  
> voting system with a link in it. You have one week to click on that  
> link and vote.
>
> - If you realize that you never got this email it can be because of  
> mail problems or that you aren't on the voter list. Send me an email  
> in either case and I will try to sort it out.
>
> - If you voted last year you are already on the list.
>
> I will accept new voters during the whole voting week! I will also  
> do my best to fix any issues with ballots gone missing in the SMTP  
> jungle.
>
> regards, Göran

Dear All,

for the record I am not voting, since the squeak board is now  
irrelevant noise.

The board cannot even manage a mission statement and maintain that  
(see below), terms of reference are a distant hope, the idea of this  
farce becoming an official legal entity, yet not seeing the need to  
have any constitution or rules at all for how it conducts itself,  
would be a joke of immense hilarity if it wasn't serious.

Here is the mission statement as advertised:

http://squeakboard.wordpress.com/our-mission/

> The Squeak Oversight Board coordinates the community’s open-source  
> development of its versatile Smalltalk environment.
>
Ok let examine this line, "co-ordinates". This involves doing some  
actual work, talking to people, discussing things weighing up ideas,  
and making considered informed decisions. "Co-ordinates" means, that  
the board doesn't actually "Do Stuff" but it relies on others to do  
stuff which it then co-ordinates through helpful advice perhaps.
> To that end, we are increasing our visibility
>
Cant argue with that.
> within the community through better communication,
>
In the introduction of "trunk", there was zero repeat ZERO pre  
discussion about the idea with those that it effected. All existing  
avenues of communication were ignored, and existing best practice was  
ignored such as using a "release mailing list" as used by the board-
endorsed "release team". Also specific requests for preferences to  
communicate on the release mailing list were ignored, when this had  
actual practical and financial implications.

In a world of modern communications when we have irc and skype and we  
are on the other side of the world and I get free calls to anywhere in  
the world 24/7. But does the board know how to use email? Andreas says  
that perhaps this was a mistake, however it wasn't his mistake, it was  
the board's mistake, to allow a new direction to be mandated without  
requiring a proposal, a consultation and a vote of sorts over a period.

As a member of the community I had to follow a formal procedure to  
satisfy the board. Members of the board are exempt from any such  
formality. Thus it is now perceived by some as a requirement to have a  
position on the board to be heard. If you have a commercial interest  
in squeak, if you do not have a position on the board, you do not have  
an equal representation as compared to others who do have a position  
on the board.

The board should be strictly impartial in relation to commercial  
interests, while it is not, it is not trustable.
> improving the release process,
>
The release process, is the bit which takes an image, adds some fixes,  
updates packages to their latest versions, adds licensing,  
documentation, sets the version number, and zips up the result.

I have just witnessed Ronald, or whatever his name is ;-) do this for  
Squeak 4.0, and it was done Manually, exactly the same as every other  
release, and the process itself took at least 3 weeks, when an  
automated process (which we already had) would take 3 minutes.

So much for improving the release process. Nothing has changed.
> joining the Software Freedom Conservancy, enabling Teams to achieve  
> their tasks,
>
This is comical. How did the board "enable" me to achieve my task. To  
do this they would have to communicate (see first paragraph) They just  
undermined everything I had done, then and told me I don't have enough  
Charisma, and "the end justifies the means".
> and integrating contributions from collaborating groups (for  
> example, Pharo, Etoys, and Croquet).
>
"integrating contributions", to me means that we treat all of these  
groups as part of the community and try to create processes that work,  
and manage some of it in common between them, and we act for them as  
an enabler.

Does the new "trunk" process introduced by the board this year do  
this? No it doesn't it, it is exclusive to squeak itself as a fork. It  
just enables more people to contribute to squeak as its own fork,  
speeding up the process of diversion between forks, It discourages the  
development of features in common with other forks, specifically it  
does not treat the development of features as distinct load-able  
entities that are integrated.

Recent statements by board members have indicated that the board  
doesnt aim to represent anyone else other than the squeak fork,  
whereas before we had a feeling of responsibility for providing tools  
and services to benefit all of our many "prodigy".

The board continues to treat previous releases as abandon-ware. We  
don't even look after our existing users.
> Our goals for this year are a **clear** release process for the 3.x  
> series,
>
Trunk doesn't have any clear indication of what will or will not be in  
it.
it doesn't have any development plan or timeline
it doesn't have any packaging system where stuff can be clearly  
organised.
it doesn't have any automated testing
it doesn't have any automated release process.
it doesn't adopt any best practices such as XP, release early and  
often so releases are not time boxed, everything is far from clear.
> a license-clean Squeak 4.0 release,
>
This was a goal. How long ago? If I had to manually rewrite every  
method effected 3 times, it could have been done quicker. The problem  
with this goal was that everyone talked about it, no one on the board  
actually did anything.

(apart from asking  the 3.11 release team leader to do the job on  
squeak 4.0, without asking the release team, and consequently leaving  
us a man down)
> a solid legal foundation,
>
The board members have resisted all attempts to suggest that a  
constitution is a necessary thing. Without it the board has no  
identity in and of itself, it is merely a collection of randomly  
selected, "charismatic" individuals. How you would achieve becoming a  
legal entity without any rules at all is anyone's guess.
> and a draft programming interface for exchanging code between systems.
>
No sign of this.

(except I have developed it recently)
> With these, we believe the community will be more effective in  
> developing for itself and in introducing the system to newcomers.
>
I agree if the board actually did any of these things it might. But at  
the moment they are still patting themselves on the back saying what a  
great "trunk" process we have got, and what wonderful charismatic  
leaders we now have. When it is the opposite process of what is needed  
if you actually sit down and think about the problem as a whole.

Anyone can hack a new image, but is the process itself capable of  
acheiveing what we want(ed) to achieve. Given that  package management  
is left to be an after thought leads me to think not.
> Please note that this is a work in progress and we appreciate any  
> comments or suggestions that you may have.
>
This is my comment.

Now for my suggestions:

If you have a commercial interest in developing with squeak, you will  
be far better off taking control and forking the image for yourself,  
maintaining your own branch. So at least you have the level of control  
needed to maintain the required stability, and the image you use will  
be maintained (by you).

Working towards this goal, of having control over your own image,  
individuals and groups who want to help will publish innovations in a  
separately managed load-able form, that are not tied to any one image.

When this mechanism is in place, none of the forks is any different to  
any other fork, each is merely a configuration of loaded packages on  
one or many starting points.

When the tools are available such that the level of control you have  
over your own image, is higher than the level of control you have over  
the image you are given by the board. The board in its current  
"glorified release team form" becomes irrelevant.

If Kent Beck or others of his calibre were running for the board then  
I would vote.

regards

Keith






Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Nicolas Cellier
Keith,
I won't try to distinguish what I consider true and false assertions
here, and will stay positive.
It's good that you have a vision, and for sure a vision larger than
squeak-trunk patch process.
But... You have to invent a process simple enough to attract
participating people.
Otherwise, you fail, no matter how noble your causes are.

Cheers

Nicolas

2010/3/10 keith <[hidden email]>:

>> Hi all!
>>
>> Ok, so tonight at 18.00 UTC the actual voting period starts. It goes like
>> this:
>>
>> - Around 18.00 UTC tonight you will get an email from the CIVS voting
>> system with a link in it. You have one week to click on that link and vote.
>>
>> - If you realize that you never got this email it can be because of mail
>> problems or that you aren't on the voter list. Send me an email in either
>> case and I will try to sort it out.
>>
>> - If you voted last year you are already on the list.
>>
>> I will accept new voters during the whole voting week! I will also do my
>> best to fix any issues with ballots gone missing in the SMTP jungle.
>>
>> regards, Göran
>
> Dear All,
>
> for the record I am not voting, since the squeak board is now irrelevant
> noise.
>
> The board cannot even manage a mission statement and maintain that (see
> below), terms of reference are a distant hope, the idea of this farce
> becoming an official legal entity, yet not seeing the need to have any
> constitution or rules at all for how it conducts itself, would be a joke of
> immense hilarity if it wasn't serious.
>
> Here is the mission statement as advertised:
>
> http://squeakboard.wordpress.com/our-mission/
>
>> The Squeak Oversight Board coordinates the community’s open-source
>> development of its versatile Smalltalk environment.
>>
> Ok let examine this line, "co-ordinates". This involves doing some actual
> work, talking to people, discussing things weighing up ideas, and making
> considered informed decisions. "Co-ordinates" means, that the board doesn't
> actually "Do Stuff" but it relies on others to do stuff which it then
> co-ordinates through helpful advice perhaps.
>>
>> To that end, we are increasing our visibility
>>
> Cant argue with that.
>>
>> within the community through better communication,
>>
> In the introduction of "trunk", there was zero repeat ZERO pre discussion
> about the idea with those that it effected. All existing avenues of
> communication were ignored, and existing best practice was ignored such as
> using a "release mailing list" as used by the board-endorsed "release team".
> Also specific requests for preferences to communicate on the release mailing
> list were ignored, when this had actual practical and financial
> implications.
>
> In a world of modern communications when we have irc and skype and we are on
> the other side of the world and I get free calls to anywhere in the world
> 24/7. But does the board know how to use email? Andreas says that perhaps
> this was a mistake, however it wasn't his mistake, it was the board's
> mistake, to allow a new direction to be mandated without requiring a
> proposal, a consultation and a vote of sorts over a period.
>
> As a member of the community I had to follow a formal procedure to satisfy
> the board. Members of the board are exempt from any such formality. Thus it
> is now perceived by some as a requirement to have a position on the board to
> be heard. If you have a commercial interest in squeak, if you do not have a
> position on the board, you do not have an equal representation as compared
> to others who do have a position on the board.
>
> The board should be strictly impartial in relation to commercial interests,
> while it is not, it is not trustable.
>>
>> improving the release process,
>>
> The release process, is the bit which takes an image, adds some fixes,
> updates packages to their latest versions, adds licensing, documentation,
> sets the version number, and zips up the result.
>
> I have just witnessed Ronald, or whatever his name is ;-) do this for Squeak
> 4.0, and it was done Manually, exactly the same as every other release, and
> the process itself took at least 3 weeks, when an automated process (which
> we already had) would take 3 minutes.
>
> So much for improving the release process. Nothing has changed.
>>
>> joining the Software Freedom Conservancy, enabling Teams to achieve their
>> tasks,
>>
> This is comical. How did the board "enable" me to achieve my task. To do
> this they would have to communicate (see first paragraph) They just
> undermined everything I had done, then and told me I don't have enough
> Charisma, and "the end justifies the means".
>>
>> and integrating contributions from collaborating groups (for example,
>> Pharo, Etoys, and Croquet).
>>
> "integrating contributions", to me means that we treat all of these groups
> as part of the community and try to create processes that work, and manage
> some of it in common between them, and we act for them as an enabler.
>
> Does the new "trunk" process introduced by the board this year do this? No
> it doesn't it, it is exclusive to squeak itself as a fork. It just enables
> more people to contribute to squeak as its own fork, speeding up the process
> of diversion between forks, It discourages the development of features in
> common with other forks, specifically it does not treat the development of
> features as distinct load-able entities that are integrated.
>
> Recent statements by board members have indicated that the board doesnt aim
> to represent anyone else other than the squeak fork, whereas before we had a
> feeling of responsibility for providing tools and services to benefit all of
> our many "prodigy".
>
> The board continues to treat previous releases as abandon-ware. We don't
> even look after our existing users.
>>
>> Our goals for this year are a **clear** release process for the 3.x
>> series,
>>
> Trunk doesn't have any clear indication of what will or will not be in it.
> it doesn't have any development plan or timeline
> it doesn't have any packaging system where stuff can be clearly organised.
> it doesn't have any automated testing
> it doesn't have any automated release process.
> it doesn't adopt any best practices such as XP, release early and often so
> releases are not time boxed, everything is far from clear.
>>
>> a license-clean Squeak 4.0 release,
>>
> This was a goal. How long ago? If I had to manually rewrite every method
> effected 3 times, it could have been done quicker. The problem with this
> goal was that everyone talked about it, no one on the board actually did
> anything.
>
> (apart from asking  the 3.11 release team leader to do the job on squeak
> 4.0, without asking the release team, and consequently leaving us a man
> down)
>>
>> a solid legal foundation,
>>
> The board members have resisted all attempts to suggest that a constitution
> is a necessary thing. Without it the board has no identity in and of itself,
> it is merely a collection of randomly selected, "charismatic" individuals.
> How you would achieve becoming a legal entity without any rules at all is
> anyone's guess.
>>
>> and a draft programming interface for exchanging code between systems.
>>
> No sign of this.
>
> (except I have developed it recently)
>>
>> With these, we believe the community will be more effective in developing
>> for itself and in introducing the system to newcomers.
>>
> I agree if the board actually did any of these things it might. But at the
> moment they are still patting themselves on the back saying what a great
> "trunk" process we have got, and what wonderful charismatic leaders we now
> have. When it is the opposite process of what is needed if you actually sit
> down and think about the problem as a whole.
>
> Anyone can hack a new image, but is the process itself capable of acheiveing
> what we want(ed) to achieve. Given that  package management is left to be an
> after thought leads me to think not.
>>
>> Please note that this is a work in progress and we appreciate any comments
>> or suggestions that you may have.
>>
> This is my comment.
>
> Now for my suggestions:
>
> If you have a commercial interest in developing with squeak, you will be far
> better off taking control and forking the image for yourself, maintaining
> your own branch. So at least you have the level of control needed to
> maintain the required stability, and the image you use will be maintained
> (by you).
>
> Working towards this goal, of having control over your own image,
> individuals and groups who want to help will publish innovations in a
> separately managed load-able form, that are not tied to any one image.
>
> When this mechanism is in place, none of the forks is any different to any
> other fork, each is merely a configuration of loaded packages on one or many
> starting points.
>
> When the tools are available such that the level of control you have over
> your own image, is higher than the level of control you have over the image
> you are given by the board. The board in its current "glorified release team
> form" becomes irrelevant.
>
> If Kent Beck or others of his calibre were running for the board then I
> would vote.
>
> regards
>
> Keith
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

keith1y

On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:

> Keith,
> I won't try to distinguish what I consider true and false assertions
> here, and will stay positive.
> It's good that you have a vision, and for sure a vision larger than
> squeak-trunk patch process.
> But... You have to invent a process simple enough to attract
> participating people.
> Otherwise, you fail, no matter how noble your causes are.
>
> Cheers
>
> Nicolas

I think contributing patches to mantis was simple enough

Keith

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Levente Uzonyi-2
On Wed, 10 Mar 2010, keith wrote:

>
> On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:
>
>> Keith,
>> I won't try to distinguish what I consider true and false assertions
>> here, and will stay positive.
>> It's good that you have a vision, and for sure a vision larger than
>> squeak-trunk patch process.
>> But... You have to invent a process simple enough to attract
>> participating people.
>> Otherwise, you fail, no matter how noble your causes are.
>>
>> Cheers
>>
>> Nicolas
>
> I think contributing patches to mantis was simple enough

That's true, but most of them were never integrated, because:
- the integrator has to have deep knowledge about the issue, the patch and
the system (this was much harder than now, because now the creator of the
patch can integrate it most of the time. IMHO this is the weakest point in
Pharo's contribution process, besides the lack of contributors.)
- patches to a "fixed point" can conflict with each other making
integration even harder

Also fine grained "cherry-picking" is not a good idea, because you just
can't predict how the patches will interact with each other.


Levente

>
> Keith
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Nicolas Cellier
2010/3/10 Levente Uzonyi <[hidden email]>:

> On Wed, 10 Mar 2010, keith wrote:
>
>>
>> On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:
>>
>>> Keith,
>>> I won't try to distinguish what I consider true and false assertions
>>> here, and will stay positive.
>>> It's good that you have a vision, and for sure a vision larger than
>>> squeak-trunk patch process.
>>> But... You have to invent a process simple enough to attract
>>> participating people.
>>> Otherwise, you fail, no matter how noble your causes are.
>>>
>>> Cheers
>>>
>>> Nicolas
>>
>> I think contributing patches to mantis was simple enough
>
> That's true, but most of them were never integrated, because:
> - the integrator has to have deep knowledge about the issue, the patch and
> the system (this was much harder than now, because now the creator of the
> patch can integrate it most of the time. IMHO this is the weakest point in
> Pharo's contribution process, besides the lack of contributors.)
> - patches to a "fixed point" can conflict with each other making integration
> even harder
>
> Also fine grained "cherry-picking" is not a good idea, because you just
> can't predict how the patches will interact with each other.
>
>
> Levente
>

Yes, I personnaly posted several uncompatible patches, so "manual"
review is necessary, and the image still is an efficient support for
that.
At the end, a different patch would be needed for squeak 3.9, 3.10,
trunk or Pharo, and as long as the code is on mantis, it is dead.
Maybe using automation to make it live - as Keith started - could
help, but under express condition to have good test coverage.
Also, automation is only good for detecting the issues, not really for
solving them, so I'm not fully convinced for the Kernel.
I presume automation should work better with packages, but beware of
combinatorial if you want to assert groups of packages...

Nicolas

>>
>> Keith
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Nicolas Cellier
2010/3/10 Nicolas Cellier <[hidden email]>:

> 2010/3/10 Levente Uzonyi <[hidden email]>:
>> On Wed, 10 Mar 2010, keith wrote:
>>
>>>
>>> On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:
>>>
>>>> Keith,
>>>> I won't try to distinguish what I consider true and false assertions
>>>> here, and will stay positive.
>>>> It's good that you have a vision, and for sure a vision larger than
>>>> squeak-trunk patch process.
>>>> But... You have to invent a process simple enough to attract
>>>> participating people.
>>>> Otherwise, you fail, no matter how noble your causes are.
>>>>
>>>> Cheers
>>>>
>>>> Nicolas
>>>
>>> I think contributing patches to mantis was simple enough
>>
>> That's true, but most of them were never integrated, because:
>> - the integrator has to have deep knowledge about the issue, the patch and
>> the system (this was much harder than now, because now the creator of the
>> patch can integrate it most of the time. IMHO this is the weakest point in
>> Pharo's contribution process, besides the lack of contributors.)
>> - patches to a "fixed point" can conflict with each other making integration
>> even harder
>>
>> Also fine grained "cherry-picking" is not a good idea, because you just
>> can't predict how the patches will interact with each other.
>>
>>
>> Levente
>>
>
> Yes, I personnaly posted several uncompatible patches, so "manual"
> review is necessary, and the image still is an efficient support for
> that.
> At the end, a different patch would be needed for squeak 3.9, 3.10,
> trunk or Pharo, and as long as the code is on mantis, it is dead.
> Maybe using automation to make it live - as Keith started - could
> help, but under express condition to have good test coverage.
> Also, automation is only good for detecting the issues, not really for
> solving them, so I'm not fully convinced for the Kernel.
> I presume automation should work better with packages, but beware of
> combinatorial if you want to assert groups of packages...
>
> Nicolas
>

I also believe in using RB 'lint' rules to detect non portable code,
and eventually rewrite rules to help updating packages.
That's not panacea, but a tool among others.

Nicolas

>>>
>>> Keith
>>>
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

keith1y
In reply to this post by Levente Uzonyi-2

I think contributing patches to mantis was simple enough

That's true, but most of them were never integrated, because:
- the integrator has to have deep knowledge about the issue, the patch and the system (this was much harder than now, because now the creator of the patch can integrate it most of the time. IMHO this is the weakest point in Pharo's contribution process, besides the lack of contributors.)
- patches to a "fixed point" can conflict with each other making integration even harder

Also fine grained "cherry-picking" is not a good idea, because you just can't predict how the patches will interact with each other.


Levente


I don't think you are understanding, we had already been using this process for over 2 years. It did work, and it worked for more than one image simultaneously, as demonstrated by LPF. It also worked for ALL the packages in Sake/Packages, not just for the kernel.

The bare minimal step forward 3.10-build image had 17 fixes in it, it demonstrated the concept well. The test script that was being used to generate an example 3.11-alpha had over 100 fixes in it. My production images have a fair few too. We didn't have a problem with this process at all. We were producing tools to automate and speed up this process, to be repeated on a monthly cycle. The work that went into that 3.11 script was then repeated in trunk, so I wasted my time on it.

If you are stupid enough to try and integrate more than 500 fixes per month then of course you will have conflicts that are a problem. However 200-300 is perfectly doable per month. We had 100 just by selecting Nicolas' fixes.

The main goal of the fixes is not to fix things per-se but to carefully re-architect things so that they become modules that can be worked upon and fixed offline, by separate individuals or teams. 

"trunk" hasn't even split up "System", which was the first thing that needed doing if you believe in modularity. We also reorganised all of the tests so that they go with the thing they are testing and are unloadable and loadable.

The trunk process is the opposite of this, in spirit because it doesn't even consider having a package management solution important enough to do first.

The fact that we didn't publish an image, was simply because the bob-process had not been completed up to the automated testing point, and that was our actual deliverable. Not that the automated build process using mantis didn't work. As I said it had already been proven.

One weak point in the plan is the lack of discipline within the community to use mantis well, and the fact that the whole system did not work offline, and was relatively fragile as a result. But part of the bob-process plan was to provide an offline code cache. Introducing trunk, undermined mantis as a source of good code, for any purpose, even supporting legacy images, and rendered the monthly bob release cycle process useless overnight.

K






Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Ken G. Brown
At 7:01 PM +0000 3/10/10, keith apparently wrote:

>>>I think contributing patches to mantis was simple enough
>>>
>>
>>That's true, but most of them were never integrated, because:
>>- the integrator has to have deep knowledge about the issue, the patch and the system (this was much harder than now, because now the creator of the patch can integrate it most of the time. IMHO this is the weakest point in Pharo's contribution process, besides the lack of contributors.)
>>- patches to a "fixed point" can conflict with each other making integration even harder
>>
>>Also fine grained "cherry-picking" is not a good idea, because you just can't predict how the patches will interact with each other.
>>
>>
>>Levente
>>
>
>I don't think you are understanding, we had already been using this process for over 2 years. It did work, and it worked for more than one image simultaneously, as demonstrated by LPF. It also worked for ALL the packages in Sake/Packages, not just for the kernel.
>
>The bare minimal step forward 3.10-build image had 17 fixes in it, it demonstrated the concept well. The test script that was being used to generate an example 3.11-alpha had over 100 fixes in it. My production images have a fair few too. We didn't have a problem with this process at all. We were producing tools to automate and speed up this process, to be repeated on a monthly cycle. The work that went into that 3.11 script was then repeated in trunk, so I wasted my time on it.
>
>If you are stupid enough to try and integrate more than 500 fixes per month then of course you will have conflicts that are a problem. However 200-300 is perfectly doable per month. We had 100 just by selecting Nicolas' fixes.
>
>The main goal of the fixes is not to fix things per-se but to carefully re-architect things so that they become modules that can be worked upon and fixed offline, by separate individuals or teams.
>
>"trunk" hasn't even split up "System", which was the first thing that needed doing if you believe in modularity. We also reorganised all of the tests so that they go with the thing they are testing and are unloadable and loadable.
>
>The trunk process is the opposite of this, in spirit because it doesn't even consider having a package management solution important enough to do first.
>
>The fact that we didn't publish an image, was simply because the bob-process had not been completed up to the automated testing point, and that was our actual deliverable. Not that the automated build process using mantis didn't work. As I said it had already been proven.
>
>One weak point in the plan is the lack of discipline within the community to use mantis well, and the fact that the whole system did not work offline, and was relatively fragile as a result. But part of the bob-process plan was to provide an offline code cache. Introducing trunk, undermined mantis as a source of good code, for any purpose, even supporting legacy images, and rendered the monthly bob release cycle process useless overnight.
>
>K

I personally used Keith's process before 'trunk' was instituted, to build a Squeak-dev image from 3.10.2, using Damien's previous scripts, via Installer, Sake/Packages and Bob the Builder. This proved out the overall process to me, and if *I* could do it, then surely anyone else could similarly have done so.

Ken G. Brown

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Nicolas Cellier
In reply to this post by keith1y
2010/3/10 Ken G. Brown <[hidden email]>:

> At 7:01 PM +0000 3/10/10, keith apparently wrote:
>>>>I think contributing patches to mantis was simple enough
>>>>
>>>
>>>That's true, but most of them were never integrated, because:
>>>- the integrator has to have deep knowledge about the issue, the patch and the system (this was much harder than now, because now the creator of the patch can integrate it most of the time. IMHO this is the weakest point in Pharo's contribution process, besides the lack of contributors.)
>>>- patches to a "fixed point" can conflict with each other making integration even harder
>>>
>>>Also fine grained "cherry-picking" is not a good idea, because you just can't predict how the patches will interact with each other.
>>>
>>>
>>>Levente
>>>
>>
>>I don't think you are understanding, we had already been using this process for over 2 years. It did work, and it worked for more than one image simultaneously, as demonstrated by LPF. It also worked for ALL the packages in Sake/Packages, not just for the kernel.
>>
>>The bare minimal step forward 3.10-build image had 17 fixes in it, it demonstrated the concept well. The test script that was being used to generate an example 3.11-alpha had over 100 fixes in it. My production images have a fair few too. We didn't have a problem with this process at all. We were producing tools to automate and speed up this process, to be repeated on a monthly cycle. The work that went into that 3.11 script was then repeated in trunk, so I wasted my time on it.
>>
>>If you are stupid enough to try and integrate more than 500 fixes per month then of course you will have conflicts that are a problem. However 200-300 is perfectly doable per month. We had 100 just by selecting Nicolas' fixes.
>>
>>The main goal of the fixes is not to fix things per-se but to carefully re-architect things so that they become modules that can be worked upon and fixed offline, by separate individuals or teams.
>>
>>"trunk" hasn't even split up "System", which was the first thing that needed doing if you believe in modularity. We also reorganised all of the tests so that they go with the thing they are testing and are unloadable and loadable.
>>
>>The trunk process is the opposite of this, in spirit because it doesn't even consider having a package management solution important enough to do first.
>>
>>The fact that we didn't publish an image, was simply because the bob-process had not been completed up to the automated testing point, and that was our actual deliverable. Not that the automated build process using mantis didn't work. As I said it had already been proven.
>>
>>One weak point in the plan is the lack of discipline within the community to use mantis well, and the fact that the whole system did not work offline, and was relatively fragile as a result. But part of the bob-process plan was to provide an offline code cache. Introducing trunk, undermined mantis as a source of good code, for any purpose, even supporting legacy images, and rendered the monthly bob release cycle process useless overnight.
>>
>>K
>
> I personally used Keith's process before 'trunk' was instituted, to build a Squeak-dev image from 3.10.2, using Damien's previous scripts, via Installer, Sake/Packages and Bob the Builder. This proved out the overall process to me, and if *I* could do it, then surely anyone else could similarly have done so.
>
> Ken G. Brown
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Levente Uzonyi-2
In reply to this post by keith1y
On Wed, 10 Mar 2010, keith wrote:

>>>
>>> I think contributing patches to mantis was simple enough
>>
>> That's true, but most of them were never integrated, because:
>> - the integrator has to have deep knowledge about the issue, the patch and
>> the system (this was much harder than now, because now the creator of the
>> patch can integrate it most of the time. IMHO this is the weakest point in
>> Pharo's contribution process, besides the lack of contributors.)
>> - patches to a "fixed point" can conflict with each other making
>> integration even harder
>>
>> Also fine grained "cherry-picking" is not a good idea, because you just
>> can't predict how the patches will interact with each other.
>>
>>
>> Levente
>>
>
> I don't think you are understanding, we had already been using this process
> for over 2 years. It did work, and it worked for more than one image
> simultaneously, as demonstrated by LPF. It also worked for ALL the packages
> in Sake/Packages, not just for the kernel.

I'm sure one could easily write a patch which would break a 3.7+LPF
image, but not a 3.10.2+LPF image.

>
> The bare minimal step forward 3.10-build image had 17 fixes in it, it
> demonstrated the concept well. The test script that was being used to
> generate an example 3.11-alpha had over 100 fixes in it. My production images
> have a fair few too. We didn't have a problem with this process at all. We
> were producing tools to automate and speed up this process, to be repeated on
> a monthly cycle. The work that went into that 3.11 script was then repeated
> in trunk, so I wasted my time on it.
>
> If you are stupid enough to try and integrate more than 500 fixes per month
> then of course you will have conflicts that are a problem. However 200-300 is
> perfectly doable per month. We had 100 just by selecting Nicolas' fixes.

I'm sure Nicolas' patches don't conflict with each other. But they
conflict with my (never published) #lowBit, #highBit, etc patches.

>
> The main goal of the fixes is not to fix things per-se but to carefully
> re-architect things so that they become modules that can be worked upon and
> fixed offline, by separate individuals or teams.
>
> "trunk" hasn't even split up "System", which was the first thing that needed
> doing if you believe in modularity. We also reorganised all of the tests so
> that they go with the thing they are testing and are unloadable and loadable.

We can do that anytime, can't we? I think it's not urgent to have a kernel
image. If we get there in 6 months or a year, it doesn't really matter to
me.

>
> The trunk process is the opposite of this, in spirit because it doesn't even
> consider having a package management solution important enough to do first.
>
> The fact that we didn't publish an image, was simply because the bob-process
> had not been completed up to the automated testing point, and that was our
> actual deliverable. Not that the automated build process using mantis didn't
> work. As I said it had already been proven.

Actually the Trunk process is similar to what you wanted to do, but it
doesn't use mantis at all and it's not automatic. Think about it like
this:
- every Monticello Configuration is a new release (we are at 133 at the
moment)
- we edit patches according to a fixed point (the last MC configuration)
- we even do it in an iterative, distributed and collaborative way with MC
- everyone can contribute from it's own image with Squeak-based tools
- you can update your image whenever you want to a newer release (MC
configuration)

Of course you can't cherry pick patches, but that doesn't work with your
process (see above).


Levente

>
> One weak point in the plan is the lack of discipline within the community to
> use mantis well, and the fact that the whole system did not work offline, and
> was relatively fragile as a result. But part of the bob-process plan was to
> provide an offline code cache. Introducing trunk, undermined mantis as a
> source of good code, for any purpose, even supporting legacy images, and
> rendered the monthly bob release cycle process useless overnight.
>
> K
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

keith1y

We can do that anytime, can't we? I think it's not urgent to have a kernel image. If we get there in 6 months or a year, it doesn't really matter to me.

That is not what the community has been saying for the past 5 years.

Having a kernel image is essential if the forking problem is to be turned into an opportunity, rather than a pain.

As I have always said, anyone can hack at a monolithic image, that is not news. In fact that is the approach that got is into this mess in the first place. If the community wants to go in a specific direction then you have to plan for it, think about it and actually work on the tools you need to achieve it.

Developing tools for 12 months, forgetting all of your goals, and going back to where you started, and then saying that you don't care if you never get to where you wanted to go, is not progress in my book.

Keith

 

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Igor Stasenko
On 11 March 2010 01:37, keith <[hidden email]> wrote:
>
> Developing tools for 12 months, forgetting all of your goals, and going back
> to where you started, and then saying that you don't care if you never get
> to where you wanted to go, is not progress in my book.

No. Why? A failure teaching us as well (and even better) than a
succcess. Of course, if we want to learn.

> Keith
>

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Levente Uzonyi-2
In reply to this post by keith1y
On Wed, 10 Mar 2010, keith wrote:

>>
>> We can do that anytime, can't we? I think it's not urgent to have a kernel
>> image. If we get there in 6 months or a year, it doesn't really matter to
>> me.
>
> That is not what the community has been saying for the past 5 years.

I'm not the community, just a member, my opinion may differ.

>
> Having a kernel image is essential if the forking problem is to be turned
> into an opportunity, rather than a pain.

I don't think anyone would like to make new forks in the near future
(except for Jecel). It's easier to cooperate than to do everything
on your own.

>
> As I have always said, anyone can hack at a monolithic image, that is not
> news. In fact that is the approach that got is into this mess in the first
> place. If the community wants to go in a specific direction then you have to
> plan for it, think about it and actually work on the tools you need to
> achieve it.
>
> Developing tools for 12 months, forgetting all of your goals, and going back
> to where you started, and then saying that you don't care if you never get to
> where you wanted to go, is not progress in my book.

"The goals

The goal of this process is to get rid of as many hurdles as possible in
the contribution process. We are trying to enable the community at large
to improve Squeak, the core of the system and its supporting libraries."

I think we are doing it pretty well.


Levente

>
> Keith
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

keith1y
In reply to this post by Igor Stasenko
Developing tools for 12 months, forgetting all of your goals, and going back
to where you started, and then saying that you don't care if you never get
to where you wanted to go, is not progress in my book.

No. Why? A failure teaching us as well (and even better) than a
succcess. Of course, if we want to learn.

Keith


--
Best regards,
Igor Stasenko AKA sig.

The only failure I saw was a failure of the board to have some minimal standards of fairness, humility, communication and respect. Pretty sad state of affairs "among friends" I think.

So having identified the failure, if you are so willing to learn how about fixing it, at the point of failure? i.e. the Board and its lack of protocol.

And while we are talking about failures and fairness, whatever happened to Squeak 5.0 Spoon etc?

K.

 



Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Igor Stasenko
On 11 March 2010 02:16, keith <[hidden email]> wrote:

> Developing tools for 12 months, forgetting all of your goals, and going back
>
> to where you started, and then saying that you don't care if you never get
>
> to where you wanted to go, is not progress in my book.
>
> No. Why? A failure teaching us as well (and even better) than a
> succcess. Of course, if we want to learn.
>
> Keith
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> The only failure I saw was a failure of the board to have some minimal
> standards of fairness, humility, communication and respect. Pretty sad state
> of affairs "among friends" I think.
> So having identified the failure, if you are so willing to learn how about
> fixing it, at the point of failure? i.e. the Board and its lack of protocol.
> And while we are talking about failures and fairness, whatever happened to
> Squeak 5.0 Spoon etc?
> K.
>

I applaud your talent on turning everything to negative plane, leaving
all positive moments behind.
I'm sorry, but i can't answer in same manner to you, because i know
that we all doing a painful mistakes sometimes.
And people who doing them, deserve to be forgiven.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Edgar De Cleene
In reply to this post by Levente Uzonyi-2



On 3/10/10 10:03 PM, "Levente Uzonyi" <[hidden email]> wrote:

> I don't think anyone would like to make new forks in the near future
> (except for Jecel). It's easier to cooperate than to do everything
> on your own.

I agree.
Hope bring all leanings of SqueakLight and MinimalMorphic to SqueakCore.
Next Monday I publish the first ReleaseReport fot it.
And my hope is , when all help and do not fight, have it as 4.2 in 9 months
from now.

> I think we are doing it pretty well.

Disagree.
1- Each core developer have his own agenda.
2- Not coordination and no goals, Keith is right on this two points.
3- Many working on 3.10 do not work in trunk.
4- Nobody except me care about how we have again the Great Squeak, the Alan
and Dan spirit.
Or at less the equivalent to 3.8 Full image.
5- Saying we have a great thing shows you don't use for more as business as
usual.

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Michael Haupt-3
Hi Edgar,

On Thu, Mar 11, 2010 at 7:19 AM, Edgar J. De Cleene
<[hidden email]> wrote:
> 2- Not coordination and no goals, Keith is right on this two points.

he is.

> 4- Nobody except me care about how we have again the Great Squeak, the Alan
> and Dan spirit.

Wrong. :-)

Best,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Edgar De Cleene



On 3/11/10 5:15 AM, "Michael Haupt" <[hidden email]> wrote:

>  4- Nobody except me care about how we have again the Great Squeak, the Alan
>> and Dan spirit.
>
> Wrong. :-)

Plese tell who.
Not Etoys people or Squeakland people.
Some of this list, developers in Core Developers doing some.
Who brings any old project to 3.10 ?

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: [Election] ...is soon upon us! Last day info

Michael Haupt-3
Hi Edgar,

On Thu, Mar 11, 2010 at 8:12 AM, Edgar J. De Cleene
<[hidden email]> wrote:
> Plese tell who.

me and some others in Potsdam ... and quite possibly some more people elsewhere.

Best,

Michael

123