Not a disaster (this time)

Hello all,

I am trying to be a good tester, and have been shot in the foot now for a couple of days.  That's no great loss, but a similar set of circumstances could be very ugly in the future.  My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline.  Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck.

I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server.  Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does.

There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive.  There isn't (at least not that I can find), and it does :(

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive.  There isn't (at least not that I can find), and it does :(

Parse error.

Monticello is a distributed versioning system, so it is highly
redundant by definition. You can't really blame anybody else if a
version your are interested in is not reachable. I usually copy
important code into my local repository.

    http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Bill,

At netstyle.ch and Cmsbox we have the rule that all projects have to  
be completely loadable from our own MC repository. I suggest to do the  
same for the reasons you mention below. You never know what happens to  
external resources...

Storing a local copy with MC should not be a problem. Actually, the  
package-cache folder should already contain the file.

Cheers,
Adrian

On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/9 Lukas Renggli <[hidden email]>:
If i understanding the problem clearly, MC checks the current contents
of all repositories, defined for package,
before saving a package, even locally.
So, if one of repositories can't be reached, this leads to error and
unability to save a local copy on hard drive.
I think that this check can be reduced to check/refresh the contents
of repository where user wants to save the package,
but not all of them.
Correct me, if i wrong.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas,

The whole server is down, and MC (at least out of the box and with some help from ScriptLoader) comes uglued over it.  I don't blame the servers; I *do* blame the design.  Adrian seems to have the defects and the workaround in mind.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli
Sent: Monday, November 09, 2009 2:19 PM
To: [hidden email]
Subject: Re: [Pharo-project] Not a disaster (this time)

> There is no need for urgent action (this is only a drill<g>), but
> there should be some redundancy in where the code is stored, and MC
> should not prevent my saving code I already have to my local drive.  
> There isn't (at least not that I can find), and it does :(

Parse error.

Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository.

    http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> If i understanding the problem clearly, MC checks the current contents
> of all repositories, defined for package,
> before saving a package, even locally.

No. Monticello saves into the selected repository and into the local
package-cache only. This is the same as you get with Git (and other
similar distributed versioning systems), when you do a "git commit"
and "git push <repository>" .

> So, if one of repositories can't be reached, this leads to error and
> unability to save a local copy on hard drive.

Monticello only loads from a selected repository, it does not try
multiple repositories. It could lead to different results depending on
from what repository you load. Again that is the same same as with
"git pull <repository>".

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli wrote:
>> There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive.  There isn't (at least not that I can find), and it does :(
>
> Parse error.
>
> Monticello is a distributed versioning system, so it is highly
> redundant by definition. You can't really blame anybody else if a
> version your are interested in is not reachable. I usually copy
> important code into my local repository.

Well, on the other hand it is extremely bad publicity if the Squeak
community's main source repository, written in Squeak, is extremely
unreliable.
How can one expect someone to switch to Squeak when the first thing is
encountering it being unreliable?


Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Adrian,

You are correct, it does contain them (thanks for mentioning that).  Saving my own copies _is_ a problem, but fortunately I do not need to do so.

How do you enforce local loads?  Do you insist on downloading everything yourselves, or do you have some type of lazy download with cancel capability?  In an ideal world, I would hope to see a tool that tries to download the latest versions, shows progress toward same, and accepts user interaction to head off a hopeless situation like today.  If the user cancels the download, then there would be an option to install from the local repository.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Adrian Lienhard
Sent: Monday, November 09, 2009 2:31 PM
To: [hidden email]
Subject: Re: [Pharo-project] Not a disaster (this time)

Hi Bill,

At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources...

Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file.

Cheers,
Adrian

On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

We don't have any automated approach. All images built load from our  
own repository. If a developer wants to add an external package or  
update an existing one, he has to save into our repository.

Adrian

On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael,

Good point.  Without starting a flame war, I find it necessary to give a big +1 to Pharo (the system and the people behind it) - I doubt I would be this far along in a move to Squeak.

Servers quit (especially Windows boxes<g>), routers fail, and ISPs have bad days.  The external world is not always visible.  There is clearly a part of MC that does not anticipate these problems, and there need to be workarounds.  It sounds like others have found them; I might build it into a future version of Migrate.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Rueger
Sent: Monday, November 09, 2009 2:57 PM
To: [hidden email]
Subject: Re: [Pharo-project] Not a disaster (this time)

Lukas Renggli wrote:
Well, on the other hand it is extremely bad publicity if the Squeak community's main source repository, written in Squeak, is extremely unreliable.
How can one expect someone to switch to Squeak when the first thing is encountering it being unreliable?


Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/9 Lukas Renggli <[hidden email]>:
>> If i understanding the problem clearly, MC checks the current contents
>> of all repositories, defined for package,
>> before saving a package, even locally.
>
> No. Monticello saves into the selected repository and into the local
> package-cache only. This is the same as you get with Git (and other
> similar distributed versioning systems), when you do a "git commit"
> and "git push <repository>" .
>
Then how do you comment this:

>I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server.  Having chosen the >package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but >apparently that's not what it does.





--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Adrian,

That's fine - it will certainly avoid the trap.

Thanks!

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Adrian Lienhard
Sent: Monday, November 09, 2009 3:06 PM
To: [hidden email]
Subject: Re: [Pharo-project] Not a disaster (this time)

We don't have any automated approach. All images built load from our own repository. If a developer wants to add an external package or update an existing one, he has to save into our repository.

Adrian

On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

As an FYI... for those using Metacello...

In Metacello you can arrange to override the repositories used for loading ... useful in cases where servers are down or offline/not accessible for other reasons ...saves you from having to edit configurations ...

I use the override for creating a repository from scratch (bootstrapping from a local disk-based repositories) when the configurations that I'm using reference the public HTTP repositories.

Dale

----- "Wilhelm K Schwab" <[hidden email]> wrote:

| Adrian,
|
| You are correct, it does contain them (thanks for mentioning that).
| Saving my own copies _is_ a problem, but fortunately I do not need to
| do so.
|
| How do you enforce local loads?  Do you insist on downloading
| everything yourselves, or do you have some type of lazy download with
| cancel capability?  In an ideal world, I would hope to see a tool that
| tries to download the latest versions, shows progress toward same, and
| accepts user interaction to head off a hopeless situation like today.
| If the user cancels the download, then there would be an option to
| install from the local repository.
|
| Bill
|
|
|
| -----Original Message-----
| From: [hidden email]
| [mailto:[hidden email]] On Behalf Of
| Adrian Lienhard
| Sent: Monday, November 09, 2009 2:31 PM
| To: [hidden email]
| Subject: Re: [Pharo-project] Not a disaster (this time)
|
| Hi Bill,
|
| At netstyle.ch and Cmsbox we have the rule that all projects have to
| be completely loadable from our own MC repository. I suggest to do the
| same for the reasons you mention below. You never know what happens to
| external resources...
|
| Storing a local copy with MC should not be a problem. Actually, the
| package-cache folder should already contain the file.
|
| Cheers,
| Adrian
|
| On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
|
| > Hello all,
| >
| > I am trying to be a good tester, and have been shot in the foot now
|
| > for a couple of days.  That's no great loss, but a similar set of
| > circumstances could be very ugly in the future.  My ailing build
| > process for RC1 is thwarted by source.squeakfoundation.org's being
| > offline.  Imagine a deadline (paying customer, mission-critical
| gizmo,
| > grant submission - whatever haunts you) and being stuck.
| >
| > I have even tried to save the FFI packages locally, and that seems
| to
| > go haywire over talking to the server.  Having chosen the package
| name
| > and a local repository, I would expect MC to take the code it has
| > locally and save it to my local drive, but apparently that's not
| what
| > it does.
| >
| > There is no need for urgent action (this is only a drill<g>), but
| > there should be some redundancy in where the code is stored, and MC
| > should not prevent my saving code I already have to my local drive.
|  
| > There isn't (at least not that I can find), and it does :(
| >
| > Bill
| >
| >
| > _______________________________________________
| > Pharo-project mailing list
| > [hidden email]
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

That is a valuable feature.  When/how does it make the decision that overrides are needed?  Does it timeout and fail-over on each attempt?  That could get painful to watch, or could be problematic on slow connections.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dale Henrichs
Sent: Monday, November 09, 2009 3:26 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Pharo-project] Not a disaster (this time)

As an FYI... for those using Metacello...

In Metacello you can arrange to override the repositories used for loading ... useful in cases where servers are down or offline/not accessible for other reasons ...saves you from having to edit configurations ...

I use the override for creating a repository from scratch (bootstrapping from a local disk-based repositories) when the configurations that I'm using reference the public HTTP repositories.

Dale

----- "Wilhelm K Schwab" <[hidden email]> wrote:

| Adrian,
|
| You are correct, it does contain them (thanks for mentioning that).
| Saving my own copies _is_ a problem, but fortunately I do not need to
| do so.
|
| How do you enforce local loads?  Do you insist on downloading
| everything yourselves, or do you have some type of lazy download with
| cancel capability?  In an ideal world, I would hope to see a tool that
| tries to download the latest versions, shows progress toward same, and
| accepts user interaction to head off a hopeless situation like today.
| If the user cancels the download, then there would be an option to
| install from the local repository.
|
| Bill
|
|
|
| -----Original Message-----
| From: [hidden email]
| [mailto:[hidden email]] On Behalf Of
| Adrian Lienhard
| Sent: Monday, November 09, 2009 2:31 PM
| To: [hidden email]
| Subject: Re: [Pharo-project] Not a disaster (this time)
|
| Hi Bill,
|
| At netstyle.ch and Cmsbox we have the rule that all projects have to
| be completely loadable from our own MC repository. I suggest to do the
| same for the reasons you mention below. You never know what happens to
| external resources...
|
| Storing a local copy with MC should not be a problem. Actually, the
| package-cache folder should already contain the file.
|
| Cheers,
| Adrian
|
| On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
|
| > Hello all,
| >
| > I am trying to be a good tester, and have been shot in the foot now
|
| > for a couple of days.  That's no great loss, but a similar set of
| > circumstances could be very ugly in the future.  My ailing build
| > process for RC1 is thwarted by source.squeakfoundation.org's being
| > offline.  Imagine a deadline (paying customer, mission-critical
| gizmo,
| > grant submission - whatever haunts you) and being stuck.
| >
| > I have even tried to save the FFI packages locally, and that seems
| to
| > go haywire over talking to the server.  Having chosen the package
| name
| > and a local repository, I would expect MC to take the code it has
| > locally and save it to my local drive, but apparently that's not
| what
| > it does.
| >
| > There is no need for urgent action (this is only a drill<g>), but
| > there should be some redundancy in where the code is stored, and MC
| > should not prevent my saving code I already have to my local drive.
|  
| > There isn't (at least not that I can find), and it does :(
| >
| > Bill
| >
| >
| > _______________________________________________
| > Pharo-project mailing list
| > [hidden email]
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

What I would like especially when coding in the train is that my  
script using a given repository
can use my local cache. I know that Installer did not support that.
Lukas is gofer supporting that behavior?

Stef


On Nov 9, 2009, at 9:06 PM, Adrian Lienhard wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Bill,

You add the overrides to the loader for a version, so you'd use the overrides in an emergency or when you wanted to explicitly use a different repository....It's literally an override - when used all packages are loaded from the override repositories.

Instead of launching a load with this expression:

  (ConfigurationOfGLASS project version: '1.0-beta.2') load: 'Dev'.

You'd use this expression:

  | version |
  version := ConfigurationOfGLASS project version: '1.0-beta.2'.
  version versionSpec loader repositoryOverrides: <list of MC repositories>.
  version load: 'Seaside3.0 Dev'.

The repository overrides are passed along throughout the load chain for dependent packages etc.

Apologies for the 'version versionSpec loader' sequence, but I've been slowly pulling various bits of capability out to the version API as demand surfaces ... After this email exchange, I'll probably pull the repositoryOverrides: message all the way out to the version:)

Dale

----- "Wilhelm K Schwab" <[hidden email]> wrote:

| That is a valuable feature.  When/how does it make the decision that
| overrides are needed?  Does it timeout and fail-over on each attempt?
| That could get painful to watch, or could be problematic on slow
| connections.
|
| Bill
|
|
|
| -----Original Message-----
| From: [hidden email]
| [mailto:[hidden email]] On Behalf Of Dale
| Henrichs
| Sent: Monday, November 09, 2009 3:26 PM
| To: [hidden email]
| Cc: [hidden email]
| Subject: Re: [Pharo-project] Not a disaster (this time)
|
| As an FYI... for those using Metacello...
|
| In Metacello you can arrange to override the repositories used for
| loading ... useful in cases where servers are down or offline/not
| accessible for other reasons ...saves you from having to edit
| configurations ...
|
| I use the override for creating a repository from scratch
| (bootstrapping from a local disk-based repositories) when the
| configurations that I'm using reference the public HTTP repositories.
|
| Dale
|
| ----- "Wilhelm K Schwab" <[hidden email]> wrote:
|
| | Adrian,
| |
| | You are correct, it does contain them (thanks for mentioning that).
|
| | Saving my own copies _is_ a problem, but fortunately I do not need
| to
| | do so.
| |
| | How do you enforce local loads?  Do you insist on downloading
| | everything yourselves, or do you have some type of lazy download
| with
| | cancel capability?  In an ideal world, I would hope to see a tool
| that
| | tries to download the latest versions, shows progress toward same,
| and
| | accepts user interaction to head off a hopeless situation like
| today.
| | If the user cancels the download, then there would be an option to
| | install from the local repository.
| |
| | Bill
| |
| |
| |
| | -----Original Message-----
| | From: [hidden email]
| | [mailto:[hidden email]] On Behalf Of
| | Adrian Lienhard
| | Sent: Monday, November 09, 2009 2:31 PM
| | To: [hidden email]
| | Subject: Re: [Pharo-project] Not a disaster (this time)
| |
| | Hi Bill,
| |
| | At netstyle.ch and Cmsbox we have the rule that all projects have to
|
| | be completely loadable from our own MC repository. I suggest to do
| the
| | same for the reasons you mention below. You never know what happens
| to
| | external resources...
| |
| | Storing a local copy with MC should not be a problem. Actually, the
|
| | package-cache folder should already contain the file.
| |
| | Cheers,
| | Adrian
| |
| | On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
| |
| | > Hello all,
| | >
| | > I am trying to be a good tester, and have been shot in the foot
| now
| |
| | > for a couple of days.  That's no great loss, but a similar set of
|
| | > circumstances could be very ugly in the future.  My ailing build
| | > process for RC1 is thwarted by source.squeakfoundation.org's being
|
| | > offline.  Imagine a deadline (paying customer, mission-critical
| | gizmo,
| | > grant submission - whatever haunts you) and being stuck.
| | >
| | > I have even tried to save the FFI packages locally, and that
| seems
| | to
| | > go haywire over talking to the server.  Having chosen the package
| | name
| | > and a local repository, I would expect MC to take the code it has
|
| | > locally and save it to my local drive, but apparently that's not
| | what
| | > it does.
| | >
| | > There is no need for urgent action (this is only a drill<g>), but
|
| | > there should be some redundancy in where the code is stored, and
| MC
| | > should not prevent my saving code I already have to my local
| drive.
| |  
| | > There isn't (at least not that I can find), and it does :(
| | >
| | > Bill
| | >
| | >
| | > _______________________________________________
| | > Pharo-project mailing list
| | > [hidden email]
| | >
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| |
| |
| | _______________________________________________
| | Pharo-project mailing list
| | [hidden email]
| | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| |
| | _______________________________________________
| | Pharo-project mailing list
| | [hidden email]
| | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I don't know what is hosted on source.squeakfoundation.org and who is
maintaining it.

www.squeaksource.com has been running pretty stable over the last few
years and silently serving its 7.5+ GB of Monticello versions. Feel
free to setup your own server, using your own hardware, bandwidth and
time; it is a distributed versioning system after all.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli wrote:

> I don't know what is hosted on source.squeakfoundation.org and who is
> maintaining it.

You are not quite getting the point.
As long as Pharo relies on *anything* hosted on unreliable servers
hosted by anyone the bad PR falls back on the Pharo community.

And if I would look at scripting language XY and something doesn't work
and the answer I get is "oh, just install your own server, it's all
distributed, stupid, don't rely on the offical servers, ..."
What do you think my reaction will be?


Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> I don't know what is hosted on source.squeakfoundation.org and who is
>> maintaining it.
>
> You are not quite getting the point.
> As long as Pharo relies on *anything* hosted on unreliable servers
> hosted by anyone the bad PR falls back on the Pharo community.

You are also not getting the point. Why would Pharo rely on
source.squeakfoundation.org?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael,

Please hold that thought on marketing.  In fairness, the problem is not so much that Pharo relies on an unreliable server (which might not even be the case - being down "now" and being down a lot are two different things) as it is that the package management tools (at least as far as I have seen) are lacking important features.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Rueger
Sent: Monday, November 09, 2009 6:10 PM
To: [hidden email]
Subject: Re: [Pharo-project] Not a disaster (this time)

Lukas Renggli wrote:

> I don't know what is hosted on source.squeakfoundation.org and who is
> maintaining it.

You are not quite getting the point.
As long as Pharo relies on *anything* hosted on unreliable servers hosted by anyone the bad PR falls back on the Pharo community.

And if I would look at scripting language XY and something doesn't work and the answer I get is "oh, just install your own server, it's all distributed, stupid, don't rely on the offical servers, ..."
What do you think my reaction will be?


Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project