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.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
