Hi all
[ACTION REQUIRED] so far the main services have been migrated:
OK - move DNS OK - move main web server 27GB OK - move mailing lists (quite some of them) 10GB OK - move main application (source.squeak.org) 17GB OK - move squeaksource.com 18GB OK - move mantis 0.08GB OK - move squeak wiki + squeak map 5GB - move jenkins (maybe) 11GB OK - move rest (eg, codespeed))
This means: - box3 still only has jenkins - box4 now only piggy-backs box2 and houses a lonely dnscache. - box2 has an old apache with these services:
board.squeak.org (is redirect: squeakboard.wordpress.com) boardblog.squeak.org (is redirect: squeakboard.wordpress.com) bfav.squeakfoundation.org download.squeak.org -> http://www.squeak.org/Download/ etoys.squeak.org exupery.squeak.org -> http://wiki.squeak.org/Exupery (should be: http://wiki.squeak.org/squeak/Exupery ?) jobs.squeak.org -> http://smalltalkjobs.dabbledb.com/ (DEAD) paste.squeak.org -> http://paste.lisp.org/new/squeak (PRACTICALLY DYSFUNCTIONAL) people.squeak.org -> http://people.squeakfoundation.org (DEAD) (www.)squeakfoundation.org -> http://www.squeak.org/Foundation -> http://www.squeak.org/board/ static.squeak.org DEAD svn.squeak.org:443 ?? UNKNOWN updates.squeakfoundation.org DEAD wwwtest.squeak.org ?? UNKNOWN
[ACTION]: 1. What should we do with jenkins? It is a _major_ effort revive it as it managed to degenerate into limbo (no jobs will run successfully at all) I'd like to see it put to rest. 2. What about the apache services?
@Brett: I do not intend to upgrade any of those hosts anymore. We would need to power-cycle which is counterproductive now and unnecessary shortly, anyway. Ok with the SFC?
Best regards -Tobias
On Sat, Nov 05, 2016 at 12:18:23AM +0100, Tobias Pape wrote:
Hi all
so far the main services have been migrated:
Outstanding, thanks!
[ACTION]:
- What should we do with jenkins? It is a _major_ effort revive it as it managed to degenerate into limbo (no jobs will run successfully at all) I'd like to see it put to rest.
I agree, put it to rest.
The current state of http://build.squeak.org reflects badly on the Squeak community. It does not demonstrate the current state of Squeak VM and image development. It has little value as a historical artifact, and few of the failing test jobs provide any useful guidance as to what they were originally supposed to have tested.
I would like to have the box3:/var/lib/jenkins flles rsynced over to rackspace so we do not lose them. That would preserve the option of bringing up a new Jenkins server and restoring the few jobs that may still be of value.
So my opinion: Save the files, but put Jenkins to rest.
Future: I would be happy to see Jenkins brought back in line in the future if there is an interest, but I think that we as a community should maintain higher standard with respect to things that are publicly displayed on http://build.squeak.org. These are things that should work, and if they do not work there should be some reasonable documentation as to what they are, who is responsible for them, and why they are not working.
Dave
+1 for retiring Jenkins.
I hope I have some time in the next few weeks to finalise and document the way we did the Squeak 5.1 release. We should then also be able to produce daily Squeak trunk bundles again.
Fabio
On Sat, 5 Nov 2016 at 03:39, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Nov 05, 2016 at 12:18:23AM +0100, Tobias Pape wrote:
Hi all
so far the main services have been migrated:
Outstanding, thanks!
[ACTION]:
- What should we do with jenkins? It is a _major_ effort revive it as it
managed to degenerate into limbo (no jobs will run successfully at all)
I'd like to see it put to rest.
I agree, put it to rest.
The current state of http://build.squeak.org reflects badly on the Squeak community. It does not demonstrate the current state of Squeak VM and image development. It has little value as a historical artifact, and few of the failing test jobs provide any useful guidance as to what they were originally supposed to have tested.
I would like to have the box3:/var/lib/jenkins flles rsynced over to rackspace so we do not lose them. That would preserve the option of bringing up a new Jenkins server and restoring the few jobs that may still be of value.
So my opinion: Save the files, but put Jenkins to rest.
Future: I would be happy to see Jenkins brought back in line in the future if there is an interest, but I think that we as a community should maintain higher standard with respect to things that are publicly displayed on http://build.squeak.org. These are things that should work, and if they do not work there should be some reasonable documentation as to what they are, who is responsible for them, and why they are not working.
Dave
Kill it. We needed to have something doing CI, and things weren't quite ready for Travis, and it looks like now it is.
Just: it takes effort to make this stuff work. Someone needs to put in the graft to keep the infrastructure running. Clearly that hasn't been me for the past few years.
frank
On Nov 5, 2016 14:33, "Fabio Niephaus" lists@fniephaus.com wrote:
+1 for retiring Jenkins.
I hope I have some time in the next few weeks to finalise and document the way we did the Squeak 5.1 release. We should then also be able to produce daily Squeak trunk bundles again.
Fabio
On Sat, 5 Nov 2016 at 03:39, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Nov 05, 2016 at 12:18:23AM +0100, Tobias Pape wrote:
Hi all
so far the main services have been migrated:
Outstanding, thanks!
[ACTION]:
- What should we do with jenkins? It is a _major_ effort revive it as
it managed to degenerate into limbo (no jobs will run successfully at all)
I'd like to see it put to rest.
I agree, put it to rest.
The current state of http://build.squeak.org reflects badly on the Squeak community. It does not demonstrate the current state of Squeak VM and image development. It has little value as a historical artifact, and few of the failing test jobs provide any useful guidance as to what they were originally supposed to have tested.
I would like to have the box3:/var/lib/jenkins flles rsynced over to rackspace so we do not lose them. That would preserve the option of bringing up a new Jenkins server and restoring the few jobs that may still be of value.
So my opinion: Save the files, but put Jenkins to rest.
Future: I would be happy to see Jenkins brought back in line in the future if there is an interest, but I think that we as a community should maintain higher standard with respect to things that are publicly displayed on http://build.squeak.org. These are things that should work, and if they do not work there should be some reasonable documentation as to what they are, who is responsible for them, and why they are not working.
Dave
On 05.11.2016, at 22:54, Frank Shearar frank.shearar@gmail.com wrote:
Kill it. We needed to have something doing CI, and things weren't quite ready for Travis, and it looks like now it is.
Just: it takes effort to make this stuff work. Someone needs to put in the graft to keep the infrastructure running. Clearly that hasn't been me for the past few years.
For now, I redirect build.squeak.org to Travis: https://travis-ci.org/squeak-smalltalk/
Best regards -Tobias
frank
On Nov 5, 2016 14:33, "Fabio Niephaus" lists@fniephaus.com wrote: +1 for retiring Jenkins.
I hope I have some time in the next few weeks to finalise and document the way we did the Squeak 5.1 release. We should then also be able to produce daily Squeak trunk bundles again.
Fabio
On Sat, 5 Nov 2016 at 03:39, David T. Lewis lewis@mail.msen.com wrote: On Sat, Nov 05, 2016 at 12:18:23AM +0100, Tobias Pape wrote:
Hi all
so far the main services have been migrated:
Outstanding, thanks!
[ACTION]:
- What should we do with jenkins? It is a _major_ effort revive it as it managed to degenerate into limbo (no jobs will run successfully at all) I'd like to see it put to rest.
I agree, put it to rest.
The current state of http://build.squeak.org reflects badly on the Squeak community. It does not demonstrate the current state of Squeak VM and image development. It has little value as a historical artifact, and few of the failing test jobs provide any useful guidance as to what they were originally supposed to have tested.
I would like to have the box3:/var/lib/jenkins flles rsynced over to rackspace so we do not lose them. That would preserve the option of bringing up a new Jenkins server and restoring the few jobs that may still be of value.
So my opinion: Save the files, but put Jenkins to rest.
Future: I would be happy to see Jenkins brought back in line in the future if there is an interest, but I think that we as a community should maintain higher standard with respect to things that are publicly displayed on http://build.squeak.org. These are things that should work, and if they do not work there should be some reasonable documentation as to what they are, who is responsible for them, and why they are not working.
Dave
On 05.11.2016, at 03:39, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Nov 05, 2016 at 12:18:23AM +0100, Tobias Pape wrote:
Hi all
so far the main services have been migrated:
Outstanding, thanks!
[ACTION]:
- What should we do with jenkins? It is a _major_ effort revive it as it managed to degenerate into limbo (no jobs will run successfully at all)
I'd like to see it put to rest.
I agree, put it to rest.
The current state of http://build.squeak.org reflects badly on the Squeak community. It does not demonstrate the current state of Squeak VM and image development. It has little value as a historical artifact, and few of the failing test jobs provide any useful guidance as to what they were originally supposed to have tested.
I would like to have the box3:/var/lib/jenkins flles rsynced over to rackspace so we do not lose them. That would preserve the option of bringing up a new Jenkins server and restoring the few jobs that may still be of value.
So my opinion: Save the files, but put Jenkins to rest.
i'm saving this stuff to david:/srv/jenkins
best -tobias
Future: I would be happy to see Jenkins brought back in line in the future if there is an interest, but I think that we as a community should maintain higher standard with respect to things that are publicly displayed on http://build.squeak.org. These are things that should work, and if they do not work there should be some reasonable documentation as to what they are, who is responsible for them, and why they are not working.
Dave
box-admins@lists.squeakfoundation.org
-
David T. Lewis -
Fabio Niephaus -
Frank Shearar -
Tobias Pape