Almost there: https://git.eclipse.org/r/78708
We're just having a problem with the TM repo, which PTP depends on. ________________________________ From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Doug Schaefer [dschae...@blackberry.com] Sent: August 10, 2016 10:29 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today They have to be enabled at the same time. That is our life at the moment. My point in the past was to not disable features between one release to the next, e.g. Neon to Oxygen. Because this… It’s much easier to disable projects that drop out than re-enable ones that have always been there. Doug. From: <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>> Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>> Date: Wednesday, August 10, 2016 at 10:01 AM To: Cross project issues <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 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<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: August 10, 2016 9:55 AM 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 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. 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 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&utm_source=link&utm_campaign=sig-email&utm_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&utm_source=link&utm_campaign=sig-email&utm_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 > -- 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<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 _______________________________________________ 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 -- Kaloyan Raev | ZEND STUDIO TEAM LEAD Rogue Wave Software, Inc. Accelerating Great Code M +359 887 648 663 www.roguewave.com<http://www.roguewave.com> / kaloyan.r...@roguewave.com<mailto:kaloyan.r...@roguewave.com> _______________________________________________ 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&utm_source=link&utm_campaign=sig-email&utm_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&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
_______________________________________________ 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
