On 02/23/2012 03:21 PM, Denis Roy wrote:
otherwise
the CI job for GMF Tooling will be forever in a sandbox, it'd
have a bad effect on the project.
I think forever is a strong word,but I don't understand why having
a job on the sandbox is bad for the project.
I understand that technically, it does not change anything, but it
is the fact of "being apart" which is annoying for the project in
term of visibility & integration in the whole Eclipse world. We
made a lot of stuff to get back GMF Tooling on the rails and to be
"in da place" as a good citizen project, it would be a pity to have
it built alone on a sandbox machine.
But it may be a misinterpretation from my part. For me the word
sandbox means "messy place for tests". I prefer well-managed places,
such as hudson.eclipse.org.
The
EGit and JGit used the sandbox for years and managed to blossom
their way from incubation into the release train.
But finally they moved to hudson.eclipse.org, probably to be with
the others ;)
Also,
be sure that if GMF Tooling job is moved to sandbox, the same
problem will happen on sandbox...
Agreed. However, having the issue manifest itself on the sandbox
will not affect 100 other projects -- just yours.
And then the issue is likely to be never resolved because it only
affects one project in a sandbox instance.
What I'm afraid of is that putting GMF Tooling apart will cost some
effort and time to get it back in. Maybe no-one will be able to do
this effort, and GMF Tooling will stay in the sandbox (forever? :P
).
Also, it is a pity that because of an Hudson issue, GMF Tooling job
gets excluded. It's just a workaround...
If no,
then it seems that the job does not cause real trouble, then
let's keep it as it and keep on enjoying life
I've seen enough Hudson-related bugs, complaints, tweets and
emails that it is clear to me that no one is enjoying life (wrt
hudson.eclipse.org), and that is why we must act.
Thanks for understanding. Matt will work with your project in
order to transition the job over to the sandbox instance with
minimal disruptions.
Technically, it's just a matter of disabling job on
hudson.eclipse.org and copying its configuration on sandbox. If
sandbox has the same ability to access signer and to publish to
download.eclipse.org, then there is not a lot of effort.
When it is done, I'd be glad to have feedback on the overall
performance benefit of moving just one job. It's just saving 100MB
on a 2GB JVM. If nothing changed, then I'll annoy to get job is back
on hudson.eclipse.org. And also when other bugs to improve
performance get fixed, we should try to reintegrate the job into
hudson.eclipse.org. And obviously, I'm eager to get conclusions from
Winston.
|