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

[Konstantin Komissarchik]

As I understand it, the end goal is to find projects that are no longer 
actively participating, but not actively participating is only bad when there 
is a breakage that requires that project to react. These breakages are 
relatively rare. So, to guard against a rare occurrence of a breakage that 
requires an inactive project to react, we subject everyone to the 
disable/enable struggle. The cost/benefit scale isn’t balancing in my mind.

I hope that the Planning Council will reconsider this policy and we can start a 
release with the content of the previous release instead of a clean slate.

Thanks,

- Konstantin



From: Kaloyan Raev___
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

[cross-project-issues-dev] JGit and EGit participation in Oxygen

[Matthias Sohn]

JGit and EGit will participate in Oxygen at offset +1

https://projects.eclipse.org/projects/technology.jgit/releases/5.0
https://projects.eclipse.org/projects/technology.egit/releases/5.0

-Matthias
___
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

[Kaloyan Raev]

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 
 on behalf of Lorenzo Bettini 

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
> 
>
>
> 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
>


--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: htt

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

[Lorenzo Bettini]

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
> 
>   
> 
> 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
> 


-- 
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
___
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

[Ed Willink]

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

[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 
To: Cross project issues , 
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 :

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 Oxyge

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

[Kaloyan Raev]

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 
 on behalf of Alexander Nyßen 

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 
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>>
 on behalf of Alexander Nyßen 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 
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
 

 on behalf of Ed Willink 
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 val

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

[Ed Willink]

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 
 on behalf of Alexander 
Nyßen 

*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 >:


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.orgon 
behalf of Ed Willink

*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.orgon 
behalf of Ed Willink

*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:

>C

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

[Alexander Nyßen]

Hi Kaloyan,

Am 09.08.2016 um 15:55 schrieb Kaloyan Raev :
> 
> 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 
>  on behalf of Alexander Nyßen 
> 
> 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 > >:
>> 
>> 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 
>>>  
>>>  
>>>  on behalf of Ed 
>>> Willink  
>>> 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,
>

Re: [cross-project-issues-dev] Repo.eclipse.org down, can't run builds

[Frederic Gurr]

Hi,

The issue has been reported
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=499393) and fixed.

Regards,

Fred

On 09.08.2016 14:40, Pascal Rapicault wrote:
> Hi,
> 
> Repo.eclipse.org is down which prevents builds to run since tycho can't
> be fetched (for example see
> https://hudson.eclipse.org/egerrit/job/EGerrit-gerrit/1914/)
> 
> Is this a known issue?
> 
> Thx
> 
> Pascal
> 
> ___
> 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
___
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

[Kaloyan Raev]

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 
 on behalf of Alexander Nyßen 

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 
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
 

 on behalf of Ed Willink 
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
 

 on behalf of Ed Willink 
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 u

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

[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 :
> 
> 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 
>>  
>>  
>>  on behalf of Ed 
>> Willink  
>> 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 
>>>  
>>>  
>>>  on behalf of Ed 
>>> Willink  
>>> 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  
 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
 

[cross-project-issues-dev] Repo.eclipse.org down, can't run builds

[Pascal Rapicault]

Hi,

Repo.eclipse.org is down which prevents builds to run since tycho can't 
be fetched (for example see 
https://hudson.eclipse.org/egerrit/job/EGerrit-gerrit/1914/)


Is this a known issue?

Thx

Pascal

___
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

[Ed Willink]

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 
 on behalf of Ed Willink 


*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 
 on behalf of Ed 
Willink 

*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 
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: +

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

[Kaloyan Raev]

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 
 on behalf of Ed Willink 

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
 

 on behalf of Ed Willink 
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 
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
alexander.nys...@itemis.de

itemis AG
Am Brambusch 1

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

[Ed Willink]

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 
 on behalf of Ed Willink 


*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 
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_ _
__alexander.nyssen@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_





This email has been checked for viruses by Avast antivirus software. _
__www.avast.com_ 

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

[Kaloyan Raev]

Hi again,


The only change required to be reverted was "[ocl] enable 6.3.0M1 for Oxygen".


You can investigate the reason for the validation failure here: 
https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE/16/console


Kaloyan


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Kaloyan Raev 

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


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 
 on behalf of Ed Willink 

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 
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
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






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





___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery 

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

[Kaloyan Raev]

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 
 on behalf of Ed Willink 

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 
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
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






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





___
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] DLTK participation in Oxygen

[Kaloyan Raev]

Hi,

DLTK will be part of Oxygen with version 5.9. Offset will be +2.
https://projects.eclipse.org/projects/technology.dltk/releases/5.9


Best regards,

Kaloyan Raev | ZEND STUDIO TEAM LEAD

Rogue Wave Software, Inc.

Accelerating Great Code

M +359 887 648 663

www.roguewave.com / kaloyan.r...@roguewave.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