subject:"Re\: \[cross\-project\-issues\-dev\] GEF Oxygen M1 contribution only partially today"

CDT  is not providing a new M1 build but needs to enable itself to use the 
Neon.0 build.
There are all kinds of project dependency loops though, and I can't enable CDT 
without
breaking the build.  While my dependencies also can't enable themselves because 
they
are waiting for CDT.

Houston, I think we have a problem.

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Ed Willink 
[e...@willink.me.uk]
Sent: August 10, 2016 9:55 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi

In the past Doug has expressed considerable scepticism about the value of M1, 
and there has been no CDT M1. Retaining the Neon.0 contribution makes sense.

You certainly need to have a coherent set of enables to get things to work. I'm 
not clear what value Gerrit adds other than introducing a confusing tool with 
extra opportunities for confusing failures; do you really want to wait for 
someone to approve/review? This is cutting edge releng by responsible 
committers. I find a traditional direct push works fine, just so long as you 
remain online to revert any accidents promptly.

Regards

Ed Willink

On 10/08/2016 14:38, Marc Khouzam wrote:
Then what we can do is enable both CDT and PTP in the same contribution.
I'll push a path to Gerrit to see how that goes.

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Kaloyan Raev [kaloya...@zend.com<mailto:kaloya...@zend.com>]
Sent: August 10, 2016 9:34 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi,

If you merge a breaking change in master, then nobody will know if further 
changes break something or not. As far as I can see, the validation fails on 
the first error.

Kaloyan

On 08/10/2016 04:25 PM, Marc Khouzam wrote:
Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although everything works at 
the feature/plugin level.

I'm leaning towards pushing the CDT enabled contribution to SimRel even though 
it currently fails.

Opinions?

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Marc Khouzam 
[marc.khou...@ericsson.com<mailto:marc.khou...@ericsson.com>]
Sent: August 10, 2016 9:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

> 3. I disabled the DLTK integration with RSE. The validation failed because 
> Linux Tools was disabled.

> 4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
> contribution, but the validation failed because CDT was disabled.

CDT is ready but dependent of org.eclipse.remote.core which is part of PTP 
(although only hosted, I believe).

Marc

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Kaloyan Raev [kaloya...@zend.com<mailto:kaloya...@zend.com>]
Sent: August 9, 2016 1:49 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi again,

I want to describe the effort I have spent in the last hours for trying to 
enable the DLTK project - a project with rather small number of dependencies.

1. I tried to enable the whole DLTK contribution. The validation failed because 
Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed because 
RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed because 
Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed because EMF 
was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful validation.

7. I partially enabled the DLTK contribution with just the DLTK Core and Ruby 
features.

8. I tried to enable the TM/RSE contribution (I am committer there too). The 
validation failed because TM Terminal depends on org.eclipse.remote, which is 
disabled.

9. I disabled the TM Terminal features. I got a successful validation.

1

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Hi

In the past Doug has expressed considerable scepticism about the value 
of M1, and there has been no CDT M1. Retaining the Neon.0 contribution 
makes sense.

You certainly need to have a coherent set of enables to get things to 
work. I'm not clear what value Gerrit adds other than introducing a 
confusing tool with extra opportunities for confusing failures; do you 
really want to wait for someone to approve/review? This is cutting edge 
releng by responsible committers. I find a traditional direct push works 
fine, just so long as you remain online to revert any accidents promptly.

Regards

Ed Willink

On 10/08/2016 14:38, Marc Khouzam wrote:

Then what we can do is enable both CDT and PTP in the same contribution.
I'll push a path to Gerrit to see how that goes.

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan 
Raev [kaloya...@zend.com]

*Sent:* August 10, 2016 9:34 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi,

If you merge a breaking change in master, then nobody will know if 
further changes break something or not. As far as I can see, the 
validation fails on the first error.

Kaloyan

On 08/10/2016 04:25 PM, Marc Khouzam wrote:

Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although 
everything works at the feature/plugin level.

I'm leaning towards pushing the CDT enabled contribution to SimRel 
even though it currently fails.

Opinions?

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc 
Khouzam [marc.khou...@ericsson.com]

*Sent:* August 10, 2016 9:12 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

> 3. I disabled the DLTK integration with RSE. The validation failed 
because Linux Tools was disabled.

> 4. I noticed in Gerrit that the Linux Tools team was trying to 
enable its contribution, but the validation failed because CDT was 
disabled.

CDT is ready but dependent of org.eclipse.remote.core which is part 
of PTP (although only hosted, I believe).

Marc

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan 
Raev [kaloya...@zend.com]

*Sent:* August 9, 2016 1:49 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi again,

I want to describe the effort I have spent in the last hours for 
trying to enable the DLTK project - a project with rather small 
number of dependencies.

1. I tried to enable the whole DLTK contribution. The validation 
failed because Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed 
because RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed 
because Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable 
its contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed 
because EMF was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful 
validation.

7. I partially enabled the DLTK contribution with just the DLTK Core 
and Ruby features.

8. I tried to enable the TM/RSE contribution (I am committer there 
too). The validation failed because TM Terminal depends on 
org.eclipse.remote, which is disabled.

9. I disabled the TM Terminal features. I got a successful validation.

10. I enabled just the RSE feature of the TM contribution.

11. I enabled the DLTK RSE feature. Still there DLTK feature that 
cannot be enabled.

I've spend quite some effort to achieve the above. I am not sure what 
is the return of this effort. And I am still not done with enabling 
DLTK. I cannot imagine what it would take to enable a more complex 
project like Andmore. Building meaningful EPP package would be 
another interesting challenge.

Kaloyan

*From:* cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Lorenzo 
Bettini <lorenzo.bett...@gmail.com>

*Sent:* Tuesday, August 9, 2016 8:02:16 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi

We (EMF Parsley) depend on Xtext as well (besides EMF).  It's not clear
to me what we should do... add our p2 site to the simrel a

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-10 Thread Kaloyan Raev

They can be enabled in the same Gerrit patch. Once the Gerrit validation 
is green, the patch can be merged.

Kaloyan

On 08/10/2016 04:38 PM, Marc Khouzam wrote:

Then what we can do is enable both CDT and PTP in the same contribution.
I'll push a path to Gerrit to see how that goes.

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan 
Raev [kaloya...@zend.com]

*Sent:* August 10, 2016 9:34 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi,

If you merge a breaking change in master, then nobody will know if 
further changes break something or not. As far as I can see, the 
validation fails on the first error.

Kaloyan

On 08/10/2016 04:25 PM, Marc Khouzam wrote:

Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although 
everything works at the feature/plugin level.

I'm leaning towards pushing the CDT enabled contribution to SimRel 
even though it currently fails.

Opinions?

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc 
Khouzam [marc.khou...@ericsson.com]

*Sent:* August 10, 2016 9:12 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

> 3. I disabled the DLTK integration with RSE. The validation failed 
because Linux Tools was disabled.

> 4. I noticed in Gerrit that the Linux Tools team was trying to 
enable its contribution, but the validation failed because CDT was 
disabled.

CDT is ready but dependent of org.eclipse.remote.core which is part 
of PTP (although only hosted, I believe).

Marc

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan 
Raev [kaloya...@zend.com]

*Sent:* August 9, 2016 1:49 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi again,

I want to describe the effort I have spent in the last hours for 
trying to enable the DLTK project - a project with rather small 
number of dependencies.

1. I tried to enable the whole DLTK contribution. The validation 
failed because Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed 
because RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed 
because Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable 
its contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed 
because EMF was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful 
validation.

7. I partially enabled the DLTK contribution with just the DLTK Core 
and Ruby features.

8. I tried to enable the TM/RSE contribution (I am committer there 
too). The validation failed because TM Terminal depends on 
org.eclipse.remote, which is disabled.

9. I disabled the TM Terminal features. I got a successful validation.

10. I enabled just the RSE feature of the TM contribution.

11. I enabled the DLTK RSE feature. Still there DLTK feature that 
cannot be enabled.

I've spend quite some effort to achieve the above. I am not sure what 
is the return of this effort. And I am still not done with enabling 
DLTK. I cannot imagine what it would take to enable a more complex 
project like Andmore. Building meaningful EPP package would be 
another interesting challenge.

Kaloyan

*From:* cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Lorenzo 
Bettini <lorenzo.bett...@gmail.com>

*Sent:* Tuesday, August 9, 2016 8:02:16 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi

We (EMF Parsley) depend on Xtext as well (besides EMF).  It's not clear
to me what we should do... add our p2 site to the simrel and push for
review and that will fail?  Or something else?

thanks in advance
Lorenzo

On 09/08/2016 18:10, Ed Willink wrote:
> Hi
>
> What if e.g. UML went AWOL?
>
> This is exactly what happened a few years ago when OCL went
> committer-less. So many projects depended and wanted to help that
> someone had to get the rule book out and decide that since Eclipse is a
> meritocracy, that the active Bugzilla contributors took precedence over
> panicking companies.
>
> The

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Now CDT fails because it needs LinuxTools, but LinuxTools also needs CDT.

I could keep enabling projects myself, but then it basically goes against the 
point of
disabling projects until they enable themselves.

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc Khouzam 
[marc.khou...@ericsson.com]
Sent: August 10, 2016 9:38 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Then what we can do is enable both CDT and PTP in the same contribution.
I'll push a path to Gerrit to see how that goes.

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan Raev 
[kaloya...@zend.com]
Sent: August 10, 2016 9:34 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi,

If you merge a breaking change in master, then nobody will know if further 
changes break something or not. As far as I can see, the validation fails on 
the first error.

Kaloyan

On 08/10/2016 04:25 PM, Marc Khouzam wrote:
Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although everything works at 
the feature/plugin level.

I'm leaning towards pushing the CDT enabled contribution to SimRel even though 
it currently fails.

Opinions?

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Marc Khouzam 
[marc.khou...@ericsson.com<mailto:marc.khou...@ericsson.com>]
Sent: August 10, 2016 9:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

> 3. I disabled the DLTK integration with RSE. The validation failed because 
> Linux Tools was disabled.

> 4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
> contribution, but the validation failed because CDT was disabled.

CDT is ready but dependent of org.eclipse.remote.core which is part of PTP 
(although only hosted, I believe).

Marc

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Kaloyan Raev [kaloya...@zend.com<mailto:kaloya...@zend.com>]
Sent: August 9, 2016 1:49 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi again,

I want to describe the effort I have spent in the last hours for trying to 
enable the DLTK project - a project with rather small number of dependencies.

1. I tried to enable the whole DLTK contribution. The validation failed because 
Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed because 
RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed because 
Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed because EMF 
was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful validation.

7. I partially enabled the DLTK contribution with just the DLTK Core and Ruby 
features.

8. I tried to enable the TM/RSE contribution (I am committer there too). The 
validation failed because TM Terminal depends on org.eclipse.remote, which is 
disabled.

9. I disabled the TM Terminal features. I got a successful validation.

10. I enabled just the RSE feature of the TM contribution.

11. I enabled the DLTK RSE feature. Still there DLTK feature that cannot be 
enabled.

I've spend quite some effort to achieve the above. I am not sure what is the 
return of this effort. And I am still not done with enabling DLTK. I cannot 
imagine what it would take to enable a more complex project like Andmore. 
Building meaningful EPP package would be another interesting challenge.

Kaloyan

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

<cross-project-issues-dev-boun...@eclipse.org><mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of Lorenzo Bettini 
<lorenzo.bett...@gmail.com><mailto:lorenzo.bett...@gmail.com>
Sent: Tuesday, August 9, 2016 8:02:16 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-10 Thread Kaloyan Raev

Hi,

If you merge a breaking change in master, then nobody will know if 
further changes break something or not. As far as I can see, the 
validation fails on the first error.

Kaloyan

On 08/10/2016 04:25 PM, Marc Khouzam wrote:

Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although everything 
works at the feature/plugin level.

I'm leaning towards pushing the CDT enabled contribution to SimRel 
even though it currently fails.

Opinions?

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc 
Khouzam [marc.khou...@ericsson.com]

*Sent:* August 10, 2016 9:12 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

> 3. I disabled the DLTK integration with RSE. The validation failed 
because Linux Tools was disabled.

> 4. I noticed in Gerrit that the Linux Tools team was trying to 
enable its contribution, but the validation failed because CDT was 
disabled.

CDT is ready but dependent of org.eclipse.remote.core which is part of 
PTP (although only hosted, I believe).

Marc

*From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan 
Raev [kaloya...@zend.com]

*Sent:* August 9, 2016 1:49 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi again,

I want to describe the effort I have spent in the last hours for 
trying to enable the DLTK project - a project with rather small number 
of dependencies.

1. I tried to enable the whole DLTK contribution. The validation 
failed because Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed 
because RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed 
because Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable 
its contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed 
because EMF was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful 
validation.

7. I partially enabled the DLTK contribution with just the DLTK Core 
and Ruby features.

8. I tried to enable the TM/RSE contribution (I am committer there 
too). The validation failed because TM Terminal depends on 
org.eclipse.remote, which is disabled.

9. I disabled the TM Terminal features. I got a successful validation.

10. I enabled just the RSE feature of the TM contribution.

11. I enabled the DLTK RSE feature. Still there DLTK feature that 
cannot be enabled.

I've spend quite some effort to achieve the above. I am not sure what 
is the return of this effort. And I am still not done with enabling 
DLTK. I cannot imagine what it would take to enable a more complex 
project like Andmore. Building meaningful EPP package would be another 
interesting challenge.

Kaloyan

*From:* cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Lorenzo 
Bettini <lorenzo.bett...@gmail.com>

*Sent:* Tuesday, August 9, 2016 8:02:16 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Hi

We (EMF Parsley) depend on Xtext as well (besides EMF).  It's not clear
to me what we should do... add our p2 site to the simrel and push for
review and that will fail?  Or something else?

thanks in advance
Lorenzo

On 09/08/2016 18:10, Ed Willink wrote:
> Hi
>
> What if e.g. UML went AWOL?
>
> This is exactly what happened a few years ago when OCL went
> committer-less. So many projects depended and wanted to help that
> someone had to get the rule book out and decide that since Eclipse is a
> meritocracy, that the active Bugzilla contributors took precedence over
> panicking companies.
>
> The same would happen again for any +1 and probably +2 project.
>
> Clients have three options:
>
> - just occasionally a dependency can be eliminated
>
> - just occasionally a dependency can be rewritten, but it may take many
> man years of effort
>
> - much more practically a dependency gets rescued and put on minimal
> maintenance (e.g. EMFq, EMFt, EMFv).
>
> So by pretending that we must wait for +1/+2 dependencies, we waste a
> lot of time for those who are trying to contribute. It is just not real.
> +1/+2's should carry over automatically.
>
> You suggest that we should notify dependencies that we are wa

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Then what we can do is enable both CDT and PTP in the same contribution.
I'll push a path to Gerrit to see how that goes.

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan Raev 
[kaloya...@zend.com]
Sent: August 10, 2016 9:34 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi,

If you merge a breaking change in master, then nobody will know if further 
changes break something or not. As far as I can see, the validation fails on 
the first error.

Kaloyan

On 08/10/2016 04:25 PM, Marc Khouzam wrote:
Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although everything works at 
the feature/plugin level.

I'm leaning towards pushing the CDT enabled contribution to SimRel even though 
it currently fails.

Opinions?

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Marc Khouzam 
[marc.khou...@ericsson.com<mailto:marc.khou...@ericsson.com>]
Sent: August 10, 2016 9:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

> 3. I disabled the DLTK integration with RSE. The validation failed because 
> Linux Tools was disabled.

> 4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
> contribution, but the validation failed because CDT was disabled.

CDT is ready but dependent of org.eclipse.remote.core which is part of PTP 
(although only hosted, I believe).

Marc

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Kaloyan Raev [kaloya...@zend.com<mailto:kaloya...@zend.com>]
Sent: August 9, 2016 1:49 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi again,

I want to describe the effort I have spent in the last hours for trying to 
enable the DLTK project - a project with rather small number of dependencies.

1. I tried to enable the whole DLTK contribution. The validation failed because 
Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed because 
RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed because 
Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed because EMF 
was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful validation.

7. I partially enabled the DLTK contribution with just the DLTK Core and Ruby 
features.

8. I tried to enable the TM/RSE contribution (I am committer there too). The 
validation failed because TM Terminal depends on org.eclipse.remote, which is 
disabled.

9. I disabled the TM Terminal features. I got a successful validation.

10. I enabled just the RSE feature of the TM contribution.

11. I enabled the DLTK RSE feature. Still there DLTK feature that cannot be 
enabled.

I've spend quite some effort to achieve the above. I am not sure what is the 
return of this effort. And I am still not done with enabling DLTK. I cannot 
imagine what it would take to enable a more complex project like Andmore. 
Building meaningful EPP package would be another interesting challenge.

Kaloyan

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

<cross-project-issues-dev-boun...@eclipse.org><mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of Lorenzo Bettini 
<lorenzo.bett...@gmail.com><mailto:lorenzo.bett...@gmail.com>
Sent: Tuesday, August 9, 2016 8:02:16 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi

We (EMF Parsley) depend on Xtext as well (besides EMF).  It's not clear
to me what we should do... add our p2 site to the simrel and push for
review and that will fail?  Or something else?

thanks in advance
Lorenzo

On 09/08/2016 18:10, Ed Willink wrote:
> Hi
>
> What if e.g. UML went AWOL?
>
> This is exactly what happened a few years ago when OCL went
> committer-less. So many projects depended and

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although everything works at 
the feature/plugin level.

I'm leaning towards pushing the CDT enabled contribution to SimRel even though 
it currently fails.

Opinions?

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc Khouzam 
[marc.khou...@ericsson.com]
Sent: August 10, 2016 9:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

> 3. I disabled the DLTK integration with RSE. The validation failed because 
> Linux Tools was disabled.

> 4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
> contribution, but the validation failed because CDT was disabled.

CDT is ready but dependent of org.eclipse.remote.core which is part of PTP 
(although only hosted, I believe).

Marc

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan Raev 
[kaloya...@zend.com]
Sent: August 9, 2016 1:49 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi again,

I want to describe the effort I have spent in the last hours for trying to 
enable the DLTK project - a project with rather small number of dependencies.

1. I tried to enable the whole DLTK contribution. The validation failed because 
Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed because 
RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed because 
Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed because EMF 
was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful validation.

7. I partially enabled the DLTK contribution with just the DLTK Core and Ruby 
features.

8. I tried to enable the TM/RSE contribution (I am committer there too). The 
validation failed because TM Terminal depends on org.eclipse.remote, which is 
disabled.

9. I disabled the TM Terminal features. I got a successful validation.

10. I enabled just the RSE feature of the TM contribution.

11. I enabled the DLTK RSE feature. Still there DLTK feature that cannot be 
enabled.

I've spend quite some effort to achieve the above. I am not sure what is the 
return of this effort. And I am still not done with enabling DLTK. I cannot 
imagine what it would take to enable a more complex project like Andmore. 
Building meaningful EPP package would be another interesting challenge.

Kaloyan

From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Lorenzo Bettini 
<lorenzo.bett...@gmail.com>
Sent: Tuesday, August 9, 2016 8:02:16 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi

We (EMF Parsley) depend on Xtext as well (besides EMF).  It's not clear
to me what we should do... add our p2 site to the simrel and push for
review and that will fail?  Or something else?

thanks in advance
Lorenzo

On 09/08/2016 18:10, Ed Willink wrote:
> Hi
>
> What if e.g. UML went AWOL?
>
> This is exactly what happened a few years ago when OCL went
> committer-less. So many projects depended and wanted to help that
> someone had to get the rule book out and decide that since Eclipse is a
> meritocracy, that the active Bugzilla contributors took precedence over
> panicking companies.
>
> The same would happen again for any +1 and probably +2 project.
>
> Clients have three options:
>
> - just occasionally a dependency can be eliminated
>
> - just occasionally a dependency can be rewritten, but it may take many
> man years of effort
>
> - much more practically a dependency gets rescued and put on minimal
> maintenance (e.g. EMFq, EMFt, EMFv).
>
> So by pretending that we must wait for +1/+2 dependencies, we waste a
> lot of time for those who are trying to contribute. It is just not real.
> +1/+2's should carry over automatically.
>
> You suggest that we should notify dependencies that we are waiting. Are
> you joking? Why should I waste my time and EMF's time by suggesting that
> it is about time for them to contribute. EMF is a -1/+1 contribution. Of
> course it should know that it should contribute.
>
> Regards
>
> Ed Willink
>
> On 09/08/2016 16:10, David M Williams wrote:
>> I am sure improvements can be made, but the key -- from

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-10 Thread Alexander Nyßen

Hi guys,

thanks to Tom and Dennis, GEF could now be fully enabled.

Cheers,
Alexander

> Am 10.08.2016 um 11:16 schrieb Ed Willink <e...@willink.me.uk>:
> 
> Hi Michael
> 
> EMFq, EMFt, EMFv have all been on minimal maintenance for the last five 
> years. Last year there was just M4, M7, RC3. The existing code is therefore 
> very stable.
> 
> The sole very part-time releng is generally busy with other priorities so you 
> could wait a long time unless you use your initiative.
> 
> Regards
> 
> Ed Willink
> 
> 
> On 10/08/2016 10:08, Wenz, Michael wrote:
>> Hi,
>> 
>> Ed, thanks for enabling EMF Validation, that brings me one step closer to 
>> being able to enable Graphiti as well.
>> 
>> Can anybody shed any light on the status of EMF Transaction? That is my last 
>> dependendency that is missing by now…
>> 
>> Thanks,
>> Michael
>> 
>> From: cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
>> [mailto:cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org>] On Behalf Of Ed 
>> Willink
>> Sent: Mittwoch, 10. August 2016 10:40
>> To: cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
>> partially today
>> 
>> Hi
>> 
>> I had to use my initiative to enable EMF Validation. Aggregation build now 
>> looks promising. With EMF, EMFv, GEF, OCL, UML2, Xpand, Xtext contributed, 
>> perhaps the worst dependency cycles are now broken.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> 
>> On 10/08/2016 09:23, Ed Willink wrote:
>> HI
>> 
>> I have authority to enable UML2 with its Neon.0 contribution, so UML2 is now 
>> enabled. OCL coming as soon as the aggreagtion build status clarifies.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 10/08/2016 08:42, Dennis Hübner wrote:
>> Hello Alex,
>> I’ve enabled EMF, Xpand and Xtext in Oxyden. There are still some 
>> dependencies missing:
>> 
>> - ODA is missing for EMF
>> - UML2 is missing for Xpand
>> 
>> … but I think it should not block you.
>> 
>> Best regards,
>> Dennis.
>> 
>> Am 08.08.2016 um 17:34 schrieb Alexander Nyßen <nys...@itemis.de 
>> <mailto:nys...@itemis.de>>:
>> 
>> Hi all,
>> 
>> I have just re-enabled the GEF repository for Oxygen and made available the 
>> Neon release version of GEF-legacy (Draw2d/GEF (MVC) 3.x, Zest 1.x) to 
>> enable downstream projects that depend on it. The GEF (formerly known as 
>> GEF4) contribution to M1 is already prepared as well, but I had to disable 
>> it for now because it depends on downstream projects (namely e(fx)clipse and 
>> Xtext) that have not updated their contributions yet. GEF will thus not be 
>> available today but on Wednesday.
>> 
>> Regards,
>> Alexander
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Principal Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-202
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de <http://www.itemis.de/>
>> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
>> 
>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
>> Fiorentino
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>> 
>> Viele Grüße,
>> Dennis Hübner
>> 
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> thi

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Hi Michael

EMFq, EMFt, EMFv have all been on minimal maintenance for the last five
years. Last year there was just M4, M7, RC3. The existing code is
therefore very stable.

The sole very part-time releng is generally busy with other priorities
so you could wait a long time unless you use your initiative.

Regards

Ed Willink

On 10/08/2016 10:08, Wenz, Michael wrote:

Hi,

Ed, thanks for enabling EMF Validation, that brings me one step closer
to being able to enable Graphiti as well.

Can anybody shed any light on the status of EMF Transaction? That is
my last dependendency that is missing by now…

Thanks,

Michael

*From:*cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of
*Ed Willink

*Sent:* Mittwoch, 10. August 2016 10:40
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today

I had to use my initiative to enable EMF Validation. Aggregation build
now looks promising. With EMF, EMFv, GEF, OCL, UML2, Xpand, Xtext
contributed, perhaps the worst dependency cycles are now broken.

Regards

Ed Willink

On 10/08/2016 09:23, Ed Willink wrote:

I have authority to enable UML2 with its Neon.0 contribution, so
UML2 is now enabled. OCL coming as soon as the aggreagtion build
status clarifies.

Regards

Ed Willink

On 10/08/2016 08:42, Dennis Hübner wrote:

Hello Alex,

I’ve enabled EMF, Xpand and Xtext in Oxyden. There are still
some dependencies missing:

- ODA is missing for EMF

- UML2 is missing for Xpand

… but I think it should not block you.

Best regards,

Dennis.

Am 08.08.2016 um 17:34 schrieb Alexander Nyßen
<nys...@itemis.de <mailto:nys...@itemis.de>>:

Hi all,

I have just re-enabled the GEF repository for Oxygen and
made available the Neon release version of GEF-legacy
(Draw2d/GEF (MVC) 3.x, Zest 1.x) to enable downstream
projects that depend on it. The GEF (formerly known as
GEF4) contribution to M1 is already prepared as well, but
I had to disable it for now because it depends on
downstream projects (namely e(fx)clipse and Xtext) that
have not updated their contributions yet. GEF will thus
not be available today but on Wednesday.

Regards,

Alexander

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743

http://www.itemis.de <http://www.itemis.de/>
alexander.nys...@itemis.de
<mailto:alexander.nys...@itemis.de>

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael
Neuhaus, Jennifer Fiorentino

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Viele Grüße,

Dennis Hübner

___

cross-project-issues-dev mailing list

cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>

To change your delivery options, retrieve your password, or unsubscribe
from this list, visit

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Avast logo

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

This email has been checked for viruses by Avast antivirus software.
www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

___

cross-project-issues-dev mailing list

cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>

To change your delivery options, retrieve your password, or unsubscribe
from this list, visit

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-10 Thread Tom Schindl

Hi Alexander,

I've enabled the e(fx)clipse runtime contribution from Neon.0. The
tooling contribution stays disabled until WTP is enabled as we use their
XML-Editors.

Tom

On 09.08.16 15:38, Alexander Nyßen wrote:
> I also fear that without enabling the Neon contributions the
> bootstrapping is not to be done. We are virtually postponing it all to
> Wednesday, when we will have to perform a piece-by-piece integration
> (probably on the level of individual features), hoping that all projects
> actually contribute something. GEF for instance depends on e(fx)clipse
> and Xtext, which - if I recollect correctly - have not even stated their
> intention to participate in Oxygen. I am keeping my fingers crossed...
> 
> Regards
> Alexander
> 
>> Am 09.08.2016 um 14:36 schrieb Ed Willink <e...@willink.me.uk
>> <mailto:e...@willink.me.uk>>:
>>
>> Hi
>>
>> Co-ordination would be good, but we have a new policy whose
>> consequences do not seem to have been appreciated.
>>
>> Indeed it is +2, and I see no successful +1 contributions. Just GEF
>> that enabled a Neon contribution to reduce its small contribution to
>> the overall deadlock.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 09/08/2016 13:27, Kaloyan Raev wrote:
>>> Hi Ed,
>>>
>>> Can't all these projects coordinate and make the necessary
>>> contributions within a short time frame without leaving master broken
>>> for a long time?
>>>
>>> It's already M1 +2 date and the rest of the projects should be able
>>> to do their contributions.
>>>
>>> Kaloyan
>>> 
>>> *From:* cross-project-issues-dev-boun...@eclipse.org 
>>> <cross-project-issues-dev-boun...@eclipse.org> on
>>> behalf of Ed Willink <e...@willink.me.uk>
>>> *Sent:* Tuesday, August 9, 2016 3:20:07 PM
>>> *To:* cross-project-issues-dev@eclipse.org
>>> *Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
>>> only partially today
>>>  
>>> Hi
>>>
>>> Feel free, but we have a policy problem.
>>>
>>> The earlier discussion was on Xtext dependencies.
>>>
>>> The build is currently failing because OCL depends on UML2 which is
>>> missing.
>>>
>>> Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or
>>> Xtext is missing.
>>>
>>> We therefore have three choices.
>>>
>>> Green all the way: No contribution is enabled till ALL prerequisites
>>> are enabled. This will be very slow because of the recursive
>>> dependencies, because relengs are not super-responsive, because it is
>>> August, because some projects never contribute at M1, and because M1
>>> used to be two rather than one weeks long.
>>>
>>> Red till green: contribute as normal, so that the validator
>>> identifies the missing contributions.
>>>
>>> The old way. Neon contributions are enabled by default.
>>>
>>> I think the old way was better, but given that we are improving, I
>>> see contribution enabling as appropriate so that the missing
>>> contributions are highlighted.
>>>
>>> AFAIAA all OCL's dependencies have declared intent so OCL can be
>>> enabled and that is what I have done.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>> On 09/08/2016 13:09, Kaloyan Raev wrote:
>>>> Hi folks,
>>>>
>>>> I don't want to break the party, but your recent changes, pushed
>>>> directly to master, broke the validation build. Thus, everyone else
>>>> who follow the clean process of contributing via Gerrit is blocked
>>>> at the moment.
>>>>
>>>> I am going to revert the last changes one by one until I get a clean
>>>> validation build.
>>>>
>>>> Please contribute your next changes via Gerrit.
>>>>
>>>> Thanks,
>>>> Kaloyan
>>>> 
>>>> *From:* cross-project-issues-dev-boun...@eclipse.org 
>>>> <cross-project-issues-dev-boun...@eclipse.org> on
>>>> behalf of Ed Willink <e...@willink.me.uk>
>>>> *Sent:* Monday, August 8, 2016 8:39:57 PM
>>>> *To:* cross-project-issues-dev@eclipse.org
>>>> *Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
>>>>

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today


Hi

I had to use my initiative to enable EMF Validation. Aggregation build 
now looks promising. With EMF, EMFv, GEF, OCL, UML2, Xpand, Xtext 
contributed, perhaps the worst dependency cycles are now broken.


Regards

Ed Willink


On 10/08/2016 09:23, Ed Willink wrote:


HI

I have authority to enable UML2 with its Neon.0 contribution, so UML2 
is now enabled. OCL coming as soon as the aggreagtion build status 
clarifies.


Regards

Ed Willink

On 10/08/2016 08:42, Dennis Hübner wrote:

Hello Alex,
I’ve enabled EMF, Xpand and Xtext in Oxyden. There are still some 
dependencies missing:


- ODA is missing for EMF
- UML2 is missing for Xpand

… but I think it should not block you.

Best regards,
Dennis.

Am 08.08.2016 um 17:34 schrieb Alexander Nyßen >:


Hi all,

I have just re-enabled the GEF repository for Oxygen and made 
available the Neon release version of GEF-legacy (Draw2d/GEF (MVC) 
3.x, Zest 1.x) to enable downstream projects that depend on it. The 
GEF (formerly known as GEF4) contribution to M1 is already prepared 
as well, but I had to disable it for now because it depends on 
downstream projects (namely e(fx)clipse and Xtext) that have not 
updated their contributions yet. GEF will thus not be available 
today but on Wednesday.


Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, 
Jennifer Fiorentino




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org 

To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Viele Grüße,
Dennis Hübner



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev





Avast logo 
 
	


This email has been checked for viruses by Avast antivirus software.
www.avast.com 
 






___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today


HI

I have authority to enable UML2 with its Neon.0 contribution, so UML2 is 
now enabled. OCL coming as soon as the aggreagtion build status clarifies.


Regards

Ed Willink

On 10/08/2016 08:42, Dennis Hübner wrote:

Hello Alex,
I’ve enabled EMF, Xpand and Xtext in Oxyden. There are still some 
dependencies missing:


- ODA is missing for EMF
- UML2 is missing for Xpand

… but I think it should not block you.

Best regards,
Dennis.

Am 08.08.2016 um 17:34 schrieb Alexander Nyßen >:


Hi all,

I have just re-enabled the GEF repository for Oxygen and made 
available the Neon release version of GEF-legacy (Draw2d/GEF (MVC) 
3.x, Zest 1.x) to enable downstream projects that depend on it. The 
GEF (formerly known as GEF4) contribution to M1 is already prepared 
as well, but I had to disable it for now because it depends on 
downstream projects (namely e(fx)clipse and Xtext) that have not 
updated their contributions yet. GEF will thus not be available today 
but on Wednesday.


Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, 
Jennifer Fiorentino




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org 

To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Viele Grüße,
Dennis Hübner



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-10 Thread Dennis Hübner

Hello Alex,
I’ve enabled EMF, Xpand and Xtext in Oxyden. There are still some dependencies 
missing:

- ODA is missing for EMF
- UML2 is missing for Xpand

… but I think it should not block you.

Best regards,
Dennis.

> Am 08.08.2016 um 17:34 schrieb Alexander Nyßen :
> 
> Hi all,
> 
> I have just re-enabled the GEF repository for Oxygen and made available the 
> Neon release version of GEF-legacy (Draw2d/GEF (MVC) 3.x, Zest 1.x) to enable 
> downstream projects that depend on it. The GEF (formerly known as GEF4) 
> contribution to M1 is already prepared as well, but I had to disable it for 
> now because it depends on downstream projects (namely e(fx)clipse and Xtext) 
> that have not updated their contributions yet. GEF will thus not be available 
> today but on Wednesday.
> 
> Regards,
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nys...@itemis.de 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
> Fiorentino
> 
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Viele Grüße,
Dennis Hübner



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Hi again,

I want to describe the effort I have spent in the last hours for trying to 
enable the DLTK project - a project with rather small number of dependencies.

1. I tried to enable the whole DLTK contribution. The validation failed because 
Mylyn was disabled.

2. I disabled the DLTK integration with Mylyn. The validation failed because 
RSE was disabled.

3. I disabled the DLTK integration with RSE. The validation failed because 
Linux Tools was disabled.

4. I noticed in Gerrit that the Linux Tools team was trying to enable its 
contribution, but the validation failed because CDT was disabled.

5. I disabled the ShellEd feature of DLTK. The validation failed because EMF 
was disabled.

6. I disabled the Tcl features of DLTK. Finally, I got a successful validation.

7. I partially enabled the DLTK contribution with just the DLTK Core and Ruby 
features.

8. I tried to enable the TM/RSE contribution (I am committer there too). The 
validation failed because TM Terminal depends on org.eclipse.remote, which is 
disabled.

9. I disabled the TM Terminal features. I got a successful validation.

10. I enabled just the RSE feature of the TM contribution.

11. I enabled the DLTK RSE feature. Still there DLTK feature that cannot be 
enabled.

I've spend quite some effort to achieve the above. I am not sure what is the 
return of this effort. And I am still not done with enabling DLTK. I cannot 
imagine what it would take to enable a more complex project like Andmore. 
Building meaningful EPP package would be another interesting challenge.

Kaloyan

From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Lorenzo Bettini 
<lorenzo.bett...@gmail.com>
Sent: Tuesday, August 9, 2016 8:02:16 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi

We (EMF Parsley) depend on Xtext as well (besides EMF).  It's not clear
to me what we should do... add our p2 site to the simrel and push for
review and that will fail?  Or something else?

thanks in advance
Lorenzo

On 09/08/2016 18:10, Ed Willink wrote:
> Hi
>
> What if e.g. UML went AWOL?
>
> This is exactly what happened a few years ago when OCL went
> committer-less. So many projects depended and wanted to help that
> someone had to get the rule book out and decide that since Eclipse is a
> meritocracy, that the active Bugzilla contributors took precedence over
> panicking companies.
>
> The same would happen again for any +1 and probably +2 project.
>
> Clients have three options:
>
> - just occasionally a dependency can be eliminated
>
> - just occasionally a dependency can be rewritten, but it may take many
> man years of effort
>
> - much more practically a dependency gets rescued and put on minimal
> maintenance (e.g. EMFq, EMFt, EMFv).
>
> So by pretending that we must wait for +1/+2 dependencies, we waste a
> lot of time for those who are trying to contribute. It is just not real.
> +1/+2's should carry over automatically.
>
> You suggest that we should notify dependencies that we are waiting. Are
> you joking? Why should I waste my time and EMF's time by suggesting that
> it is about time for them to contribute. EMF is a -1/+1 contribution. Of
> course it should know that it should contribute.
>
> Regards
>
> Ed Willink
>
> On 09/08/2016 16:10, David M Williams wrote:
>> I am sure improvements can be made, but the key -- from my point of
>> view -- is that projects smooth out their processes and dependencies,
>> rather than "the big guy in the sky" blindly makes everything work
>> just fine for everyone by making a lot of assumptions that may or may
>> not be accurate. To force something positive out of this difficult
>> period of time, it does give projects an opportunity to think through
>> your dependencies and if you really want or have to depend on them.
>> For one, completely made up example, what would you do if "UML
>> Project" decided not to participate any more? What if it was
>> "terminated"? What is your contingency plan? Does something need to be
>> refactored? Made optional? Or, perhaps even move to some other project?
>
>
>
> 
> Avast logo
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com<http://www.avast.com>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
>
>
>
>
> _

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today


Hi

What if e.g. UML went AWOL?

This is exactly what happened a few years ago when OCL went 
committer-less. So many projects depended and wanted to help that 
someone had to get the rule book out and decide that since Eclipse is a 
meritocracy, that the active Bugzilla contributors took precedence over 
panicking companies.


The same would happen again for any +1 and probably +2 project.

Clients have three options:

- just occasionally a dependency can be eliminated

- just occasionally a dependency can be rewritten, but it may take many 
man years of effort


- much more practically a dependency gets rescued and put on minimal 
maintenance (e.g. EMFq, EMFt, EMFv).


So by pretending that we must wait for +1/+2 dependencies, we waste a 
lot of time for those who are trying to contribute. It is just not real. 
+1/+2's should carry over automatically.


You suggest that we should notify dependencies that we are waiting. Are 
you joking? Why should I waste my time and EMF's time by suggesting that 
it is about time for them to contribute. EMF is a -1/+1 contribution. Of 
course it should know that it should contribute.


Regards

Ed Willink

On 09/08/2016 16:10, David M Williams wrote:
I am sure improvements can be made, but the key -- from my point of 
view -- is that projects smooth out their processes and dependencies, 
rather than "the big guy in the sky" blindly makes everything work 
just fine for everyone by making a lot of assumptions that may or may 
not be accurate. To force something positive out of this difficult 
period of time, it does give projects an opportunity to think through 
your dependencies and if you really want or have to depend on them. 
For one, completely made up example, what would you do if "UML 
Project" decided not to participate any more? What if it was 
"terminated"? What is your contingency plan? Does something need to be 
refactored? Made optional? Or, perhaps even move to some other project?




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-09 Thread David M Williams

From my point of view, here are a couple of observations. 

This is not a new requirement or procedure, we have done it this way for 
several releases. 
We used to "do it" (that is, disable contributions) at M4 if projects had 
not yet declared intent or filed a release record, and there was an equal 
amount complaining about "why now? My contribution has been working all 
along and now it is broken because some dependency was disabled because 
there is suddenly something new someone has to do". So, better to be M1, 
rather than M4, IMHO. 

Another part of the problem: there seems to by a "myth" that projects 
merely have declare intent and have a release record, period. Not true. 
You must also contribute to the build. 

Another part of the problem: projects seem to think their dependencies are 
all aware of the issue and will fix themselves eventually. I do not know 
why, but that seems not to be the case. So, I suggest if you are waiting 
on a dependency, to let them know, either though their dev list or open a 
bug on them. It is always true that you are responsible for communicating 
to the projects you depend on, letting them know what you need, etc. That 
is still the case here. 

Another part of the problem: projects seem to think that their +n day is 
THE day they should contribute. Not true. It is the LAST day they can 
contribute (with out announcing here on cross-project list). As a 
practical workflow, once projects "declare", they should enable what ever 
they have at that point, even if later on, on their LAST day to 
contribute, they update their contribution. And this is true every 
milestone. A "warm-up" contribution is always a good idea before making 
your final contribution. 

A possible part of the problem: Some projects may think their "release 
record" needs to be accompanied by a "complete plan". This is not true. If 
you have one, fine. But the projects release plan is something that can 
and should be updated "as you go" since it is bound to change as 
development progresses. 

The only issue we do not account for well is when a "whole team" is on 
vacation or working with a client for the entire months of July and August 
(keeping in mind, some teams are one or two people)  -- but, seems to me 
that part of a well ran project is to know what deadlines are coming up 
and to plan accordingly -- perhaps have a backup person submit the change, 
open a bugzilla/Gerrit patch asking that someone else contribute it, since 
their release engineer or project lead is absent. 

Perhaps too part of the problem is that some projects do not understand 
the reasoning for "disabling everyone" and so they stubbornly ignore M1 
since it is not important to them. The reason it is important to "us" (the 
Planning Council) to disable the projects and request projects declare and 
enable themselves is that we have few ways to know if a project has become 
inactive or disfunctional. So this is one modest attempt to make sure the 
project is functional enough to at least "declare" and "contribute to a 
build". 

And, lastly, yes, M1 is often a rather poor milestone, from a Simultaneous 
Release point of view. 

I am sure improvements can be made, but the key -- from my point of view 
-- is that projects smooth out their processes and dependencies, rather 
than "the big guy in the sky" blindly makes everything work just fine for 
everyone by making a lot of assumptions that may or may not be accurate. 
To force something positive out of this difficult period of time, it does 
give projects an opportunity to think through your dependencies and if you 
really want or have to depend on them. For one, completely made up 
example, what would you do if "UML Project" decided not to participate any 
more? What if it was "terminated"? What is your contingency plan? Does 
something need to be refactored? Made optional? Or, perhaps even move to 
some other project? 

I hope at least some of these comments are constructive. Spread the word. 
(And open some bugs if you are waiting on someone). 





From:   Alexander Nyßen <nys...@itemis.de>
To:     Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   08/09/2016 10:14 AM
Subject:Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
onlypartially today
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi Kaloyan,

Am 09.08.2016 um 15:55 schrieb Kaloyan Raev <kaloya...@zend.com>:

I really miss the root cause of the issue…

I don't understand how does it help breaking the SimRel build now and 
hoping everything will be fine by the end of tomorrow.

I also do not think that breaking the build to enforce downstream 
contributions is the way to go, as it blocks all contributions via Gerrit.


As far as I understand, there are a few project

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Thanks for clarifying!


Now I understand what this "new policy" means. And I have noticed that the DLTK 
contribution is disabled too (like all the rest). I tried to enable it and the 
validation failed because the Mylyn contribution is disabled...


Well... this new policy is really evil. It significantly complicates the Oxygen 
participation process. It turns out that the announcement mails do not make any 
sense. Every participating project should go and enable their contribution 
(even if there is nothing new to contribute), in the correct order, and if 
anyone misses doing it then the complete train is off the rails...


IMHO, we should either revert this new policy ASAP or declare Oxygen M1 a 
failure.


Kaloyan


From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Alexander Nyßen 
<nys...@itemis.de>
Sent: Tuesday, August 9, 2016 5:14:07 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi Kaloyan,

Am 09.08.2016 um 15:55 schrieb Kaloyan Raev 
<kaloya...@zend.com<mailto:kaloya...@zend.com>>:

I really miss the root cause of the issue…

I don't understand how does it help breaking the SimRel build now and hoping 
everything will be fine by the end of tomorrow.

I also do not think that breaking the build to enforce downstream contributions 
is the way to go, as it blocks all contributions via Gerrit.


As far as I understand, there are a few projects that depend on each other. Is 
there any cycle in the dependency graph?

Even if there is no cycle (which could well be on the level of projects), there 
are several downstream dependencies (Ed and I have already pointed out two).


We are not building the Oxygen SimRel from scratch. It is based on the Neon 
state.

No, it isn’t. The Neon contributions are all disabled by default.

What have changed so significantly during Oxygen M1 so these project cannot 
stage their contributions incrementally?

Nothing. Because of the downstream dependencies that exist, there is a lot of 
bootstrapping required for M1. As the Neon contributions are disabled, enabling 
a feature can only be performed after all prerequisites have been contributed 
to M1. This is the root cause...


Kaloyan

Regards,
Alexander


From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Alexander Nyßen <nys...@itemis.de<mailto:nys...@itemis.de>>
Sent: Tuesday, August 9, 2016 4:38:00 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

I also fear that without enabling the Neon contributions the bootstrapping is 
not to be done. We are virtually postponing it all to Wednesday, when we will 
have to perform a piece-by-piece integration (probably on the level of 
individual features), hoping that all projects actually contribute something. 
GEF for instance depends on e(fx)clipse and Xtext, which - if I recollect 
correctly - have not even stated their intention to participate in Oxygen. I am 
keeping my fingers crossed...

Regards
Alexander

Am 09.08.2016 um 14:36 schrieb Ed Willink 
<e...@willink.me.uk<mailto:e...@willink.me.uk>>:

Hi

Co-ordination would be good, but we have a new policy whose consequences do not 
seem to have been appreciated.

Indeed it is +2, and I see no successful +1 contributions. Just GEF that 
enabled a Neon contribution to reduce its small contribution to the overall 
deadlock.

Regards

Ed Willink

On 09/08/2016 13:27, Kaloyan Raev wrote:
Hi Ed,

Can't all these projects coordinate and make the necessary contributions within 
a short time frame without leaving master broken for a long time?

It's already M1 +2 date and the rest of the projects should be able to do their 
contributions.

Kaloyan

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
<cross-project-issues-dev-boun...@eclipse.org><mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of Ed Willink <e...@willink.me.uk><mailto:e...@willink.me.uk>
Sent: Tuesday, August 9, 2016 3:20:07 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi

Feel free, but we have a policy problem.

The earlier discussion was on Xtext dependencies.

The build is currently failing because OCL depends on UML2 which is missing.

Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext is 
missing.

We therefore have three choices.

Green all the way:

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

Hi Kaloyan

Unfortunately the new policy means that we are building Oxygen M1 from
scratch. All Neon state has been disabled. Yes there are many cyclic
dependencies, often involving Xtext, that won't be able to contribute
successfully until EMF is enabled. EMF (via Xcore) now depends on Xtext.

Regards

Ed Willink

On 09/08/2016 14:55, Kaloyan Raev wrote:

I really miss the root cause of the issue...

I don't understand how does it help breaking the SimRel build now and
hoping everything will be fine by the end of tomorrow.

As far as I understand, there are a few projects that depend on each
other. Is there any cycle in the dependency graph?

We are not building the Oxygen SimRel from scratch. It is based on the
Neon state. What have changed so significantly during Oxygen M1 so
these project cannot stage their contributions incrementally?

Kaloyan

*From:* cross-project-issues-dev-boun...@eclipse.org
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Alexander
Nyßen <nys...@itemis.de>

*Sent:* Tuesday, August 9, 2016 4:38:00 PM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today
I also fear that without enabling the Neon contributions the
bootstrapping is not to be done. We are virtually postponing it all to
Wednesday, when we will have to perform a piece-by-piece integration
(probably on the level of individual features), hoping that all
projects actually contribute something. GEF for instance depends on
e(fx)clipse and Xtext, which - if I recollect correctly - have not
even stated their intention to participate in Oxygen. I am keeping my
fingers crossed...

Regards
Alexander

Am 09.08.2016 um 14:36 schrieb Ed Willink <e...@willink.me.uk
<mailto:e...@willink.me.uk>>:

Co-ordination would be good, but we have a new policy whose
consequences do not seem to have been appreciated.

Indeed it is +2, and I see no successful +1 contributions. Just GEF
that enabled a Neon contribution to reduce its small contribution to
the overall deadlock.

Regards

Ed Willink

On 09/08/2016 13:27, Kaloyan Raev wrote:

Hi Ed,

Can't all these projects coordinate and make the necessary
contributions within a short time frame without leaving master
broken for a long time?

It's already M1 +2 date and the rest of the projects should be able
to do their contributions.

Kaloyan

*From:*cross-project-issues-dev-boun...@eclipse.org<cross-project-issues-dev-boun...@eclipse.org>on
behalf of Ed Willink<e...@willink.me.uk>

*Sent:*Tuesday, August 9, 2016 3:20:07 PM
*To:*cross-project-issues-dev@eclipse.org
*Subject:*Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today

Feel free, but we have a policy problem.

The earlier discussion was on Xtext dependencies.

The build is currently failing because OCL depends on UML2 which is
missing.

Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or
Xtext is missing.

We therefore have three choices.

Green all the way: No contribution is enabled till ALL prerequisites
are enabled. This will be very slow because of the recursive
dependencies, because relengs are not super-responsive, because it
is August, because some projects never contribute at M1, and because
M1 used to be two rather than one weeks long.

Red till green: contribute as normal, so that the validator
identifies the missing contributions.

The old way. Neon contributions are enabled by default.

I think the old way was better, but given that we are improving, I
see contribution enabling as appropriate so that the missing
contributions are highlighted.

AFAIAA all OCL's dependencies have declared intent so OCL can be
enabled and that is what I have done.

Regards

Ed Willink

On 09/08/2016 13:09, Kaloyan Raev wrote:

Hi folks,

I don't want to break the party, but your recent changes, pushed
directly to master, broke the validation build. Thus, everyone else
who follow the clean process of contributing via Gerrit is blocked
at the moment.

I am going to revert the last changes one by one until I get a
clean validation build.

Please contribute your next changes via Gerrit.

Thanks,
Kaloyan

*From:*cross-project-issues-dev-boun...@eclipse.org<cross-project-issues-dev-boun...@eclipse.org>on
behalf of Ed Willink<e...@willink.me.uk>

*Sent:*Monday, August 8, 2016 8:39:57 PM
*To:*cross-project-issues-dev@eclipse.org
*Subject:*Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today

Hi
XText has declared intent. XText releases asynchronously, so it is
very likely that Xtext 2.10 crosses the boundary.
It seems unhelpful that you have inhibited a

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-09 Thread Alexander Nyßen

Hi Kaloyan,

Am 09.08.2016 um 15:55 schrieb Kaloyan Raev <kaloya...@zend.com>:
> 
> I really miss the root cause of the issue…
> 
> I don't understand how does it help breaking the SimRel build now and hoping 
> everything will be fine by the end of tomorrow.

I also do not think that breaking the build to enforce downstream contributions 
is the way to go, as it blocks all contributions via Gerrit.

> 
> As far as I understand, there are a few projects that depend on each other. 
> Is there any cycle in the dependency graph?

Even if there is no cycle (which could well be on the level of projects), there 
are several downstream dependencies (Ed and I have already pointed out two).

> 
> We are not building the Oxygen SimRel from scratch. It is based on the Neon 
> state.

No, it isn’t. The Neon contributions are all disabled by default.

> What have changed so significantly during Oxygen M1 so these project cannot 
> stage their contributions incrementally?

Nothing. Because of the downstream dependencies that exist, there is a lot of 
bootstrapping required for M1. As the Neon contributions are disabled, enabling 
a feature can only be performed after all prerequisites have been contributed 
to M1. This is the root cause...

> 
> Kaloyan

Regards,
Alexander

> 
> From: cross-project-issues-dev-boun...@eclipse.org 
> <cross-project-issues-dev-boun...@eclipse.org> on behalf of Alexander Nyßen 
> <nys...@itemis.de>
> Sent: Tuesday, August 9, 2016 4:38:00 PM
> To: Cross project issues
> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
> partially today
> 
> I also fear that without enabling the Neon contributions the bootstrapping is 
> not to be done. We are virtually postponing it all to Wednesday, when we will 
> have to perform a piece-by-piece integration (probably on the level of 
> individual features), hoping that all projects actually contribute something. 
> GEF for instance depends on e(fx)clipse and Xtext, which - if I recollect 
> correctly - have not even stated their intention to participate in Oxygen. I 
> am keeping my fingers crossed...
> 
> Regards
> Alexander
> 
>> Am 09.08.2016 um 14:36 schrieb Ed Willink <e...@willink.me.uk 
>> <mailto:e...@willink.me.uk>>:
>> 
>> Hi
>> 
>> Co-ordination would be good, but we have a new policy whose consequences do 
>> not seem to have been appreciated.
>> 
>> Indeed it is +2, and I see no successful +1 contributions. Just GEF that 
>> enabled a Neon contribution to reduce its small contribution to the overall 
>> deadlock.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 09/08/2016 13:27, Kaloyan Raev wrote:
>>> Hi Ed,
>>> 
>>> Can't all these projects coordinate and make the necessary contributions 
>>> within a short time frame without leaving master broken for a long time?
>>> 
>>> It's already M1 +2 date and the rest of the projects should be able to do 
>>> their contributions.
>>> 
>>> Kaloyan
>>> From: cross-project-issues-dev-boun...@eclipse.org 
>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
>>> <cross-project-issues-dev-boun...@eclipse.org> 
>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed 
>>> Willink <e...@willink.me.uk> <mailto:e...@willink.me.uk>
>>> Sent: Tuesday, August 9, 2016 3:20:07 PM
>>> To: cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
>>> partially today
>>> 
>>> Hi
>>> 
>>> Feel free, but we have a policy problem.
>>> 
>>> The earlier discussion was on Xtext dependencies.
>>> 
>>> The build is currently failing because OCL depends on UML2 which is missing.
>>> 
>>> Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext is 
>>> missing.
>>> 
>>> We therefore have three choices.
>>> 
>>> Green all the way: No contribution is enabled till ALL prerequisites are 
>>> enabled. This will be very slow because of the recursive dependencies, 
>>> because relengs are not super-responsive, because it is August, because 
>>> some projects never contribute at M1, and because M1 used to be two rather 
>>> than one weeks long.
>>> 
>>> Red till green: contribute as normal, so that the validator identifies the 
>>> missing contributions.
>>> 
>>> The old way. Neon contributions are enabl

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

I really miss the root cause of the issue...


I don't understand how does it help breaking the SimRel build now and hoping 
everything will be fine by the end of tomorrow.


As far as I understand, there are a few projects that depend on each other. Is 
there any cycle in the dependency graph?


We are not building the Oxygen SimRel from scratch. It is based on the Neon 
state. What have changed so significantly during Oxygen M1 so these project 
cannot stage their contributions incrementally?


Kaloyan


From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Alexander Nyßen 
<nys...@itemis.de>
Sent: Tuesday, August 9, 2016 4:38:00 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

I also fear that without enabling the Neon contributions the bootstrapping is 
not to be done. We are virtually postponing it all to Wednesday, when we will 
have to perform a piece-by-piece integration (probably on the level of 
individual features), hoping that all projects actually contribute something. 
GEF for instance depends on e(fx)clipse and Xtext, which - if I recollect 
correctly - have not even stated their intention to participate in Oxygen. I am 
keeping my fingers crossed...

Regards
Alexander

Am 09.08.2016 um 14:36 schrieb Ed Willink 
<e...@willink.me.uk<mailto:e...@willink.me.uk>>:

Hi

Co-ordination would be good, but we have a new policy whose consequences do not 
seem to have been appreciated.

Indeed it is +2, and I see no successful +1 contributions. Just GEF that 
enabled a Neon contribution to reduce its small contribution to the overall 
deadlock.

Regards

Ed Willink

On 09/08/2016 13:27, Kaloyan Raev wrote:
Hi Ed,

Can't all these projects coordinate and make the necessary contributions within 
a short time frame without leaving master broken for a long time?

It's already M1 +2 date and the rest of the projects should be able to do their 
contributions.

Kaloyan

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
<cross-project-issues-dev-boun...@eclipse.org><mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of Ed Willink <e...@willink.me.uk><mailto:e...@willink.me.uk>
Sent: Tuesday, August 9, 2016 3:20:07 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi

Feel free, but we have a policy problem.

The earlier discussion was on Xtext dependencies.

The build is currently failing because OCL depends on UML2 which is missing.

Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext is 
missing.

We therefore have three choices.

Green all the way: No contribution is enabled till ALL prerequisites are 
enabled. This will be very slow because of the recursive dependencies, because 
relengs are not super-responsive, because it is August, because some projects 
never contribute at M1, and because M1 used to be two rather than one weeks 
long.

Red till green: contribute as normal, so that the validator identifies the 
missing contributions.

The old way. Neon contributions are enabled by default.

I think the old way was better, but given that we are improving, I see 
contribution enabling as appropriate so that the missing contributions are 
highlighted.

AFAIAA all OCL's dependencies have declared intent so OCL can be enabled and 
that is what I have done.

Regards

Ed Willink

On 09/08/2016 13:09, Kaloyan Raev wrote:
Hi folks,

I don't want to break the party, but your recent changes, pushed directly to 
master, broke the validation build. Thus, everyone else who follow the clean 
process of contributing via Gerrit is blocked at the moment.

I am going to revert the last changes one by one until I get a clean validation 
build.

Please contribute your next changes via Gerrit.

Thanks,
Kaloyan

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
<cross-project-issues-dev-boun...@eclipse.org><mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of Ed Willink <e...@willink.me.uk><mailto:e...@willink.me.uk>
Sent: Monday, August 8, 2016 8:39:57 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today

Hi
XText has declared intent. XText releases asynchronously, so it is very likely 
that Xtext 2.10 crosses the boundary.
It seems unhelpful that you have inhibited aggregation contributions just 
because the XText releng has not realized how much trouble your enabled=false 
is

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

2016-08-09 Thread Alexander Nyßen

I also fear that without enabling the Neon contributions the bootstrapping is 
not to be done. We are virtually postponing it all to Wednesday, when we will 
have to perform a piece-by-piece integration (probably on the level of 
individual features), hoping that all projects actually contribute something. 
GEF for instance depends on e(fx)clipse and Xtext, which - if I recollect 
correctly - have not even stated their intention to participate in Oxygen. I am 
keeping my fingers crossed...

Regards
Alexander

> Am 09.08.2016 um 14:36 schrieb Ed Willink <e...@willink.me.uk>:
> 
> Hi
> 
> Co-ordination would be good, but we have a new policy whose consequences do 
> not seem to have been appreciated.
> 
> Indeed it is +2, and I see no successful +1 contributions. Just GEF that 
> enabled a Neon contribution to reduce its small contribution to the overall 
> deadlock.
> 
> Regards
> 
> Ed Willink
> 
> On 09/08/2016 13:27, Kaloyan Raev wrote:
>> Hi Ed,
>> 
>> Can't all these projects coordinate and make the necessary contributions 
>> within a short time frame without leaving master broken for a long time?
>> 
>> It's already M1 +2 date and the rest of the projects should be able to do 
>> their contributions.
>> 
>> Kaloyan
>> From: cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
>> <cross-project-issues-dev-boun...@eclipse.org> 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed 
>> Willink <e...@willink.me.uk> <mailto:e...@willink.me.uk>
>> Sent: Tuesday, August 9, 2016 3:20:07 PM
>> To: cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
>> partially today
>> 
>> Hi
>> 
>> Feel free, but we have a policy problem.
>> 
>> The earlier discussion was on Xtext dependencies.
>> 
>> The build is currently failing because OCL depends on UML2 which is missing.
>> 
>> Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext is 
>> missing.
>> 
>> We therefore have three choices.
>> 
>> Green all the way: No contribution is enabled till ALL prerequisites are 
>> enabled. This will be very slow because of the recursive dependencies, 
>> because relengs are not super-responsive, because it is August, because some 
>> projects never contribute at M1, and because M1 used to be two rather than 
>> one weeks long.
>> 
>> Red till green: contribute as normal, so that the validator identifies the 
>> missing contributions.
>> 
>> The old way. Neon contributions are enabled by default.
>> 
>> I think the old way was better, but given that we are improving, I see 
>> contribution enabling as appropriate so that the missing contributions are 
>> highlighted.
>> 
>> AFAIAA all OCL's dependencies have declared intent so OCL can be enabled and 
>> that is what I have done.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 09/08/2016 13:09, Kaloyan Raev wrote:
>>> Hi folks,
>>> 
>>> I don't want to break the party, but your recent changes, pushed directly 
>>> to master, broke the validation build. Thus, everyone else who follow the 
>>> clean process of contributing via Gerrit is blocked at the moment.
>>> 
>>> I am going to revert the last changes one by one until I get a clean 
>>> validation build.
>>> 
>>> Please contribute your next changes via Gerrit.
>>> 
>>> Thanks,
>>> Kaloyan
>>> From: cross-project-issues-dev-boun...@eclipse.org 
>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
>>> <cross-project-issues-dev-boun...@eclipse.org> 
>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed 
>>> Willink <e...@willink.me.uk> <mailto:e...@willink.me.uk>
>>> Sent: Monday, August 8, 2016 8:39:57 PM
>>> To: cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
>>> partially today
>>> 
>>> Hi
>>> XText has declared intent. XText releases asynchronously, so it is very 
>>> likely that Xtext 2.10 crosses the boundary.
>>> It seems unhelpful that you have inhibited aggregation contributions just 
>>> because the XText releng has not realized how much trouble your 
>>

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today


Hi


Co-ordination would be good, but we have a new policy whose consequences 
do not seem to have been appreciated.



Indeed it is +2, and I see no successful +1 contributions. Just GEF that 
enabled a Neon contribution to reduce its small contribution to the 
overall deadlock.



Regards


Ed Willink


On 09/08/2016 13:27, Kaloyan Raev wrote:


Hi Ed,


Can't all these projects coordinate and make the necessary 
contributions within a short time frame without leaving master broken 
for a long time?



It's already M1 +2 date and the rest of the projects should be able to 
do their contributions.



Kaloyan


*From:* cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed Willink 
<e...@willink.me.uk>

*Sent:* Tuesday, August 9, 2016 3:20:07 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today


Hi


Feel free, but we have a policy problem.


The earlier discussion was on Xtext dependencies.


The build is currently failing because OCL depends on UML2 which is 
missing.



Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext 
is missing.



We therefore have three choices.


Green all the way: No contribution is enabled till ALL prerequisites 
are enabled. This will be very slow because of the recursive 
dependencies, because relengs are not super-responsive, because it is 
August, because some projects never contribute at M1, and because M1 
used to be two rather than one weeks long.



Red till green: contribute as normal, so that the validator identifies 
the missing contributions.



The old way. Neon contributions are enabled by default.


I think the old way was better, but given that we are improving, I see 
contribution enabling as appropriate so that the missing contributions 
are highlighted.



AFAIAA all OCL's dependencies have declared intent so OCL can be 
enabled and that is what I have done.



Regards


Ed Willink


On 09/08/2016 13:09, Kaloyan Raev wrote:


Hi folks,


I don't want to break the party, but your recent changes, pushed 
directly to master, broke the validation build. Thus, everyone else 
who follow the clean process of contributing via Gerrit is blocked at 
the moment.



I am going to revert the last changes one by one until I get a clean 
validation build.



Please contribute your next changes via Gerrit.


Thanks,

Kaloyan


*From:* cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed 
Willink <e...@willink.me.uk>

*Sent:* Monday, August 8, 2016 8:39:57 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today


Hi

XText has declared intent. XText releases asynchronously, so it is 
very likely that Xtext 2.10 crosses the boundary.


It seems unhelpful that you have inhibited aggregation contributions 
just because the XText releng has not realized how much trouble your 
enabled=false is causing.


I'll enable OCL so that things improve as soon as XText and friends 
appear.


Regards

Ed Willink

On 08/08/2016 18:27, David M Williams wrote:

> Can we have the Neon contributions available as in previous years?

Projects can do that, if they want -- as long as it is still "fits in".
But it is up to the project. They need to "declare intent" and 
provide a release record, AND THEN re-enable what every contribution 
they want to make.


Thanks,





From: Ed Willink <e...@willink.me.uk>
To: cross-project-issues-dev@eclipse.org,
Date: 08/08/2016 12:13 PM
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi

OCL too cannot be enabled until Xtext is enabled.

I feel that this attempt to bootstrap from nothing is going to make 
for some very tight late coordination.


Can we have the Neon contributions available as in previous years?

If enabled="false" is required to enforce announced participation, 
surely it would be better to apply it just after M2 to all projects 
that have made no SimRel commit since Neon?


Regards

Ed Willink


On 08/08/2016 16:34, Alexander Nyßen wrote:
Hi all,

I have just re-enabled the GEF repository for Oxygen and made 
available the Neon release version of GEF-legacy (Draw2d/GEF (MVC) 
3.x, Zest 1.x) to enable downstream projects that depend on it. The 
GEF (formerly known as GEF4) contribution to M1 is already prepared 
as well, but I had to disable it for now because it depends on 
downstream projects (namely e(fx)clipse and Xtext

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today


Hi


Feel free, but we have a policy problem.


The earlier discussion was on Xtext dependencies.


The build is currently failing because OCL depends on UML2 which is missing.


Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext 
is missing.



We therefore have three choices.


Green all the way: No contribution is enabled till ALL prerequisites are 
enabled. This will be very slow because of the recursive dependencies, 
because relengs are not super-responsive, because it is August, because 
some projects never contribute at M1, and because M1 used to be two 
rather than one weeks long.



Red till green: contribute as normal, so that the validator identifies 
the missing contributions.



The old way. Neon contributions are enabled by default.


I think the old way was better, but given that we are improving, I see 
contribution enabling as appropriate so that the missing contributions 
are highlighted.



AFAIAA all OCL's dependencies have declared intent so OCL can be enabled 
and that is what I have done.



Regards


Ed Willink


On 09/08/2016 13:09, Kaloyan Raev wrote:


Hi folks,


I don't want to break the party, but your recent changes, pushed 
directly to master, broke the validation build. Thus, everyone else 
who follow the clean process of contributing via Gerrit is blocked at 
the moment.



I am going to revert the last changes one by one until I get a clean 
validation build.



Please contribute your next changes via Gerrit.


Thanks,

Kaloyan


*From:* cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed Willink 
<e...@willink.me.uk>

*Sent:* Monday, August 8, 2016 8:39:57 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today


Hi

XText has declared intent. XText releases asynchronously, so it is 
very likely that Xtext 2.10 crosses the boundary.


It seems unhelpful that you have inhibited aggregation contributions 
just because the XText releng has not realized how much trouble your 
enabled=false is causing.


I'll enable OCL so that things improve as soon as XText and friends 
appear.


Regards

Ed Willink

On 08/08/2016 18:27, David M Williams wrote:

> Can we have the Neon contributions available as in previous years?

Projects can do that, if they want -- as long as it is still "fits in".
But it is up to the project. They need to "declare intent" and 
provide a release record, AND THEN re-enable what every contribution 
they want to make.


Thanks,





From: Ed Willink <e...@willink.me.uk>
To: cross-project-issues-dev@eclipse.org,
Date: 08/08/2016 12:13 PM
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today

Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi

OCL too cannot be enabled until Xtext is enabled.

I feel that this attempt to bootstrap from nothing is going to make 
for some very tight late coordination.


Can we have the Neon contributions available as in previous years?

If enabled="false" is required to enforce announced participation, 
surely it would be better to apply it just after M2 to all projects 
that have made no SimRel commit since Neon?


Regards

Ed Willink


On 08/08/2016 16:34, Alexander Nyßen wrote:
Hi all,

I have just re-enabled the GEF repository for Oxygen and made 
available the Neon release version of GEF-legacy (Draw2d/GEF (MVC) 
3.x, Zest 1.x) to enable downstream projects that depend on it. The 
GEF (formerly known as GEF4) contribution to M1 is already prepared 
as well, but I had to disable it for now because it depends on 
downstream projects (namely e(fx)clipse and Xtext) that have not 
updated their contributions yet. GEF will thus not be available today 
but on Wednesday.


Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743
_
__http://www.itemis.de_ <http://www.itemis.de/>_
__alexander.nyssen@itemis.de_ <mailto:alexander.nys...@itemis.de>

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, 
Jennifer Fiorentino






___
cross-project-issues-dev mailing list
_cross-project-issues-dev@eclipse.org_ 
<mailto:cross-project-issues-dev@eclipse.org>
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_



-

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today