Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
Greetings, I'm sorry if this has been brought up and discussed elsewhere already. But there is a severe bug in EGit that makes EGit 2.3.0 shipped in Juno SR2 a high risk for users. See here for details: http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html Am 19.02.2013 18:04, schrieb David M Williams: This week or next, update your b3aggrcon files with your final location so the Juno aggregator could in theory be ran again. We don't plan to, but, you never know. (And, don't forget to update Kepler, if you are using the same input for that.) Given that there is a severe bug in EGit. Isn't there a chance to update the repo and the packages with EGit 2.3.1? I understand that it's very late in the game. But the packages will stay there forever on Eclipse.org for download by everbody. Those packages will contain an EGit version that contains a know bug which may delete uncommitted source code in a working copy. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org http://wagenknecht.org/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
Am 22.02.2013 11:33, schrieb Markus Knauer: - If I were a member of the EGit team, I would try to educate my users how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other channels... They are trying really hard. But honestly, would you download a software that has a disclaimer next to the download link which says hey, this is broken; you need to update afterwards? IMHO, in the current state of SR2, such a disclaimer has to be put somewhere on the download page. When it's really too late for SR2, the plan should be made for a SR2a. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org http://wagenknecht.org/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
This would also help us to properly deal with: https://bugs.eclipse.org/bugs/show_bug.cgi?id=401477 Cheers Alexander Am 22.02.2013 um 11:55 schrieb Gunnar Wagenknecht gun...@wagenknecht.org: When it's really too late for SR2, the plan should be made for a SR2a. -- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 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, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
I think we need to look at respinning SR2. For the last 18 months we have been pushing the entire community towards git, so now introducing a significant regression into eGit would just be bad news for our users. From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Markus Knauer Sent: February-22-13 5:33 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps No, I wasn't aware of this bug which is a bit scary, thanks for bringing it up here on cross-projects. Today I am trying very hard to stay calm, but it seems that this is not that easy. Some of my thoughts... - I think it's too late to stop Juno SR2 with this kind of bug. I would proceed today as planned, everything else seems to involve a very high risk. - Discuss possible workarounds/solutions for Juno SR2 in parallel... - If I were a member of the EGit team, I would try to educate my users how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other channels... Regards, Markus On Fri, Feb 22, 2013 at 10:44 AM, Gunnar Wagenknecht gun...@wagenknecht.org wrote: Greetings, I'm sorry if this has been brought up and discussed elsewhere already. But there is a severe bug in EGit that makes EGit 2.3.0 shipped in Juno SR2 a high risk for users. See here for details: http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html Am 19.02.2013 18:04, schrieb David M Williams: This week or next, update your b3aggrcon files with your final location so the Juno aggregator could in theory be ran again. We don't plan to, but, you never know. (And, don't forget to update Kepler, if you are using the same input for that.) Given that there is a severe bug in EGit. Isn't there a chance to update the repo and the packages with EGit 2.3.1? I understand that it's very late in the game. But the packages will stay there forever on Eclipse.org for download by everbody. Those packages will contain an EGit version that contains a know bug which may delete uncommitted source code in a working copy. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org http://wagenknecht.org/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- ### EclipseSource Group Telefon: +49 721 664733-0 (GMT +2) Telefax: +49 721 66473329 http://eclipsesource.com http://eclipsesource.com/ Innoopract Informationssysteme GmbH Lammstrasse 21, 76133 Karlsruhe Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
+1 for respinning, and declaring Juno SR2 early next week. Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Skerrett Sent: Friday, February 22, 2013 2:19 PM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps I think we need to look at respinning SR2. For the last 18 months we have been pushing the entire community towards git, so now introducing a significant regression into eGit would just be bad news for our users. From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Markus Knauer Sent: February-22-13 5:33 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps No, I wasn't aware of this bug which is a bit scary, thanks for bringing it up here on cross-projects. Today I am trying very hard to stay calm, but it seems that this is not that easy. Some of my thoughts... - I think it's too late to stop Juno SR2 with this kind of bug. I would proceed today as planned, everything else seems to involve a very high risk. - Discuss possible workarounds/solutions for Juno SR2 in parallel... - If I were a member of the EGit team, I would try to educate my users how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other channels... Regards, Markus On Fri, Feb 22, 2013 at 10:44 AM, Gunnar Wagenknecht gun...@wagenknecht.orgmailto:gun...@wagenknecht.org wrote: Greetings, I'm sorry if this has been brought up and discussed elsewhere already. But there is a severe bug in EGit that makes EGit 2.3.0 shipped in Juno SR2 a high risk for users. See here for details: http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html Am 19.02.2013 18:04, schrieb David M Williams: This week or next, update your b3aggrcon files with your final location so the Juno aggregator could in theory be ran again. We don't plan to, but, you never know. (And, don't forget to update Kepler, if you are using the same input for that.) Given that there is a severe bug in EGit. Isn't there a chance to update the repo and the packages with EGit 2.3.1? I understand that it's very late in the game. But the packages will stay there forever on Eclipse.org for download by everbody. Those packages will contain an EGit version that contains a know bug which may delete uncommitted source code in a working copy. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.orgmailto:gun...@wagenknecht.org http://wagenknecht.org/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- ### EclipseSource Group Telefon: +49 721 664733-0 (GMT +2) Telefax: +49 721 66473329 http://eclipsesource.comhttp://eclipsesource.com/ Innoopract Informationssysteme GmbH Lammstrasse 21, 76133 Karlsruhe Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
*If* respinning SR2 is in order, is it possible to include m2e 1.3.1 as well (instead of 1.3.0)? This is far less critical than eGit, ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=400520 / http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=95b254ecec2b1cb723a6d2ae4fb7a47a394c2dcb) but it's a very safe change and would spare users the hassle to manually update m2e. Just saying :-) Fred On Fri, Feb 22, 2013 at 2:31 PM, Oberhuber, Martin martin.oberhu...@windriver.com wrote: +1 for respinning, and declaring Juno SR2 early next week. ** ** Thanks, Martin -- *Martin Oberhuber*, SMTS / Product Architect – Development Tools, *Wind River* direct +43.662.457915.85 fax +43.662.457915.6 ** ** *From:* cross-project-issues-dev-boun...@eclipse.org [mailto: cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Ian Skerrett *Sent:* Friday, February 22, 2013 2:19 PM *To:* 'Cross project issues' *Subject:* Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps ** ** I think we need to look at respinning SR2. For the last 18 months we have been pushing the entire community towards git, so now introducing a significant regression into eGit would just be bad news for our users. ** ** ** ** ** ** *From:* cross-project-issues-dev-boun...@eclipse.org [ mailto:cross-project-issues-dev-boun...@eclipse.orgcross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Markus Knauer *Sent:* February-22-13 5:33 AM *To:* Cross project issues *Subject:* Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps ** ** No, I wasn't aware of this bug which is a bit scary, thanks for bringing it up here on cross-projects. Today I am trying very hard to stay calm, but it seems that this is not that easy. Some of my thoughts... - I think it's too late to stop Juno SR2 with this kind of bug. I would proceed today as planned, everything else seems to involve a very high risk. - Discuss possible workarounds/solutions for Juno SR2 in parallel... - If I were a member of the EGit team, I would try to educate my users how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other channels... Regards, Markus On Fri, Feb 22, 2013 at 10:44 AM, Gunnar Wagenknecht gun...@wagenknecht.org wrote: Greetings, I'm sorry if this has been brought up and discussed elsewhere already. But there is a severe bug in EGit that makes EGit 2.3.0 shipped in Juno SR2 a high risk for users. See here for details: http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html Am 19.02.2013 18:04, schrieb David M Williams: ** ** This week or next, update your b3aggrcon files with your final location so the Juno aggregator could in theory be ran again. We don't plan to, but, you never know. (And, don't forget to update Kepler, if you are using the same input for that.) ** ** Given that there is a severe bug in EGit. Isn't there a chance to update the repo and the packages with EGit 2.3.1? I understand that it's very late in the game. But the packages will stay there forever on Eclipse.org for download by everbody. Those packages will contain an EGit version that contains a know bug which may delete uncommitted source code in a working copy. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org http://wagenknecht.org/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- ### EclipseSource Group Telefon: +49 721 664733-0 (GMT +2) Telefax: +49 721 66473329 http://eclipsesource.com ** ** Innoopract Informationssysteme GmbH Lammstrasse 21, 76133 Karlsruhe Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Have you tried turning it off and on again - The IT Crowd ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Wait ... don't release yet!
I'm obviously a little late with my Wait message, but given the data damaging bug reported by EGit, We need to think this through and come up with an alternative plan. All those plans would involve not releasing today. I'll call for an Emergency meeting of the Planning Council today at 1:00 PM Eastern to discuss possible approaches, solutions, and actions required. Off hand, a complete respin cycle would take at least a week, maybe two, but there might be ways to simply remove EGit, putting it back at its SR1 level, producing that better known quantity, and letting EGit follow their own release schedule, as they have been. Sorry for the late Wait notice. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
2013/2/22 Gunnar Wagenknecht gun...@wagenknecht.org Am 22.02.2013 11:33, schrieb Markus Knauer: - If I were a member of the EGit team, I would try to educate my users how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other channels... They are trying really hard. But honestly, would you download a software that has a disclaimer next to the download link which says hey, this is broken; you need to update afterwards? IMHO, in the current state of SR2, such a disclaimer has to be put somewhere on the download page. When it's really too late for SR2, the plan should be made for a SR2a. +1 what's the authority which can decide this ? Let me know when a decision is made, I'll standby to update our contribution for Juno SR2 or SR2a to EGit 2.3.1. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Build.eclipse.org Down
it's up again I just started a jgit build -- Matthias 2013/2/22 Denis Roy denis@eclipse.org Restore is complete, and Matt is kicking Hudson as I type this. Thanks, Denis On 02/22/2013 08:54 AM, Eric Gwin wrote: Any news? A cursory look at build.eclipse.org shows what appears to be a completed restore (/shared), but I still cannot get to Hudson. Thanks much. Eric On 21/02/2013 4:29 PM, Denis Roy wrote: /shared is in the process of being restored. Unfortunately, it is absolutely huge, so it is taking a while 224GB done out of 894GB, restoring at about 40 MB/sec. Denis On 02/21/2013 04:26 PM, Alexander Nyßen wrote: Denis, when trying to run my promotion script (in order to prepare the GEF 3.8.2 release), I run into the problem that file permissions do not seem to be properly restored on /shared, i.e. I am for instance not allowed to access /shared/jobs/gef-maintenance. Cheers Alexander Am 21.02.2013 um 22:21 schrieb Alexander Nyßen alexander.nys...@itemis.de: I still can't access hudson.eclipse.org... Cheers Alexander Am 21.02.2013 um 20:17 schrieb Denis Roy denis@eclipse.org: build.eclipse.org is back online, and /shared is being restored. Apologies for the long delay. Denis On 02/21/2013 01:50 PM, Dennis Hübner wrote: Am 21.02.2013 um 17:45 schrieb Denis Roy: FWIW, the failed hard drive in /shared is an almost 9-year-old IBM piece that has been taking a beating 24/7. Quality iron right there, folks. Sounds like binford 3000 hard drive. hr hr hr hr. :) Regards, Dennis Hübner Xtext Commiter / Build Engineer ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet!
2013/2/22 David M Williams david_willi...@us.ibm.com I'm obviously a little late with my Wait message, but given the data damaging bug reported by EGit, We need to think this through and come up with an alternative plan. All those plans would involve not releasing today. I'll call for an Emergency meeting of the Planning Council today at 1:00 PM Eastern to discuss possible approaches, solutions, and actions required. Off hand, a complete respin cycle would take at least a week, maybe two, but there might be ways to simply remove EGit, putting it back at its SR1 level, producing that better known quantity, and letting EGit follow their own release schedule, as they have been. Sorry for the late Wait notice. SR1 is EGit 2.1 EGit candidates we could include: 2.3.1 which contains the bugfix for the data damaging bug 2.2.0 released in Dec 2.1.0 released with Juno SR1 I am on standby to update the EGit contribution to whatever version you decide on. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet!
Hi David, On 22/02/2013 14:14, David M Williams wrote: All those plans would involve not releasing today. Just wondering, if this Wait ... don't release yet! also implies individual projects. We (I) have already published our bits as planned (Only announce to the forum is pending). Giving our non-dependency on EGit/JGit projects I guess we may carry on with the plan, right ? Cheers, Adolfo. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet!
Hi David, Thanks. Unreleasing is quite straightforward: - Removing a composed children p2 repository (the target release) - A minor change commit and push to hidden the downloadable zips. Going for that, then. Cheers, Adolfo. On 22/02/2013 14:29, David M Williams wrote: Individual projects should wait also. We are a Simultaneous Release after all. If you have already pushed your bits I don't think heroics are needed to undo, but I would at least wait to announce. There's often issues with someone trying to update one thing, but another thing isn't released yet, so p2 reports, errors, etc. So, best to wait until we know what the plan is. Apologies for the late notice, From: Adolfo Sanchez-Barbudo Herrera adolfo...@gmail.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 02/22/2013 09:25 AM Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David, On 22/02/2013 14:14, David M Williams wrote: All those plans would involve not releasing today. Just wondering, if this Wait ... don't release yet! also implies individual projects. We (I) have already published our bits as planned (Only announce to the forum is pending). Giving our non-dependency on EGit/JGit projects I guess we may carry on with the plan, right ? Cheers, Adolfo. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet!
2013/2/22 Matthias Sohn matthias.s...@gmail.com 2013/2/22 David M Williams david_willi...@us.ibm.com I'm obviously a little late with my Wait message, but given the data damaging bug reported by EGit, We need to think this through and come up with an alternative plan. All those plans would involve not releasing today. I'll call for an Emergency meeting of the Planning Council today at 1:00 PM Eastern to discuss possible approaches, solutions, and actions required. Off hand, a complete respin cycle would take at least a week, maybe two, but there might be ways to simply remove EGit, putting it back at its SR1 level, producing that better known quantity, and letting EGit follow their own release schedule, as they have been. Sorry for the late Wait notice. SR1 is EGit 2.1 EGit candidates we could include: 2.3.1 which contains the bugfix for the data damaging bug 2.2.0 released in Dec 2.1.0 released with Juno SR1 I am on standby to update the EGit contribution to whatever version you decide on. I have prepared a commit to update the EGit SR2 contribution to 2.3.1, b3 validation looks fine. It contains the following fixes on top of 2.3.0: - JGit Fixes: Bug: 401249 (that's fixing the data damaging bug), Bug: 400818 (minor fix for handling of ChangeIds in staging view) - EGit Fixes: Bug: 400662 (minor fix to fix rendering of commit message editor on Windows) If planning council decides for a respin I am ready to push this change. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet!
As already documented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=401477, I did the same for gef yesterday, so when re-running the aggregator, gef 3.8.2 should now be properly included as well. Cheers Alexander Am 22.02.2013 um 15:57 schrieb Matthias Sohn matthias.s...@gmail.com: 2013/2/22 Matthias Sohn matthias.s...@gmail.com 2013/2/22 David M Williams david_willi...@us.ibm.com I'm obviously a little late with my Wait message, but given the data damaging bug reported by EGit, We need to think this through and come up with an alternative plan. All those plans would involve not releasing today. I'll call for an Emergency meeting of the Planning Council today at 1:00 PM Eastern to discuss possible approaches, solutions, and actions required. Off hand, a complete respin cycle would take at least a week, maybe two, but there might be ways to simply remove EGit, putting it back at its SR1 level, producing that better known quantity, and letting EGit follow their own release schedule, as they have been. Sorry for the late Wait notice. SR1 is EGit 2.1 EGit candidates we could include: 2.3.1 which contains the bugfix for the data damaging bug 2.2.0 released in Dec 2.1.0 released with Juno SR1 I am on standby to update the EGit contribution to whatever version you decide on. I have prepared a commit to update the EGit SR2 contribution to 2.3.1, b3 validation looks fine. It contains the following fixes on top of 2.3.0: - JGit Fixes: Bug: 401249 (that's fixing the data damaging bug), Bug: 400818 (minor fix for handling of ChangeIds in staging view) - EGit Fixes: Bug: 400662 (minor fix to fix rendering of commit message editor on Windows) If planning council decides for a respin I am ready to push this change. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 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, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Build.eclipse.org Down
Thanks very much. I started a build, and it failed: /opt/users/hudsonbuild/workspace/eclipselink-nightly-master/autobuild.xml:430: java.io.FileNotFoundException: /shared/rt/eclipselink/handoff-file-build-master-v20130222-547208e.dat (Permission denied) Looks like Hudson may need some permissions updates. -Eric On 22/02/2013 8:55 AM, Denis Roy wrote: Restore is complete, and Matt is kicking Hudson as I type this. Thanks, Denis On 02/22/2013 08:54 AM, Eric Gwin wrote: Any news? A cursory look at build.eclipse.org shows what appears to be a completed restore (/shared), but I still cannot get to Hudson. Thanks much. Eric On 21/02/2013 4:29 PM, Denis Roy wrote: /shared is in the process of being restored. Unfortunately, it is absolutely huge, so it is taking a while 224GB done out of 894GB, restoring at about 40 MB/sec. Denis On 02/21/2013 04:26 PM, Alexander Nyßen wrote: Denis, when trying to run my promotion script (in order to prepare the GEF 3.8.2 release), I run into the problem that file permissions do not seem to be properly restored on /shared, i.e. I am for instance not allowed to access /shared/jobs/gef-maintenance. Cheers Alexander Am 21.02.2013 um 22:21 schrieb Alexander Nyßen alexander.nys...@itemis.de mailto:alexander.nys...@itemis.de: I still can't access hudson.eclipse.org http://hudson.eclipse.org/... Cheers Alexander Am 21.02.2013 um 20:17 schrieb Denis Roy denis@eclipse.org mailto:denis@eclipse.org: build.eclipse.org http://build.eclipse.org/ is back online, and /shared is being restored. Apologies for the long delay. Denis On 02/21/2013 01:50 PM, Dennis Hübner wrote: Am 21.02.2013 um 17:45 schrieb Denis Roy: FWIW, the failed hard drive in /shared is an almost 9-year-old IBM piece that has been taking a beating 24/7. Quality iron right there, folks. Sounds like binford 3000 hard drive. hr hr hr hr. :) Regards, Dennis Hübner Xtext Commiter / Build Engineer ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps
Not the release day email I was expecting to wake up to, but I agree that a respin seems in order. In this case quality trumps deadlines. Cheers, Ian On 22 Feb 2013 06:19, Matthias Sohn matthias.s...@gmail.com wrote: 2013/2/22 Gunnar Wagenknecht gun...@wagenknecht.org Am 22.02.2013 11:33, schrieb Markus Knauer: - If I were a member of the EGit team, I would try to educate my users how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other channels... They are trying really hard. But honestly, would you download a software that has a disclaimer next to the download link which says hey, this is broken; you need to update afterwards? IMHO, in the current state of SR2, such a disclaimer has to be put somewhere on the download page. When it's really too late for SR2, the plan should be made for a SR2a. +1 what's the authority which can decide this ? Let me know when a decision is made, I'll standby to update our contribution for Juno SR2 or SR2a to EGit 2.3.1. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Build.eclipse.org Down
I'm re-applying the ACLs for hudsonBuild. It is taking forever. Denis On 02/22/2013 10:07 AM, Eric Gwin wrote: Thanks very much. I started a build, and it failed: /opt/users/hudsonbuild/workspace/eclipselink-nightly-master/autobuild.xml:430: java.io.FileNotFoundException: /shared/rt/eclipselink/handoff-file-build-master-v20130222-547208e.dat (Permission denied) Looks like Hudson may need some permissions updates. -Eric On 22/02/2013 8:55 AM, Denis Roy wrote: Restore is complete, and Matt is kicking Hudson as I type this. Thanks, Denis On 02/22/2013 08:54 AM, Eric Gwin wrote: Any news? A cursory look at build.eclipse.org shows what appears to be a completed restore (/shared), but I still cannot get to Hudson. Thanks much. Eric On 21/02/2013 4:29 PM, Denis Roy wrote: /shared is in the process of being restored. Unfortunately, it is absolutely huge, so it is taking a while 224GB done out of 894GB, restoring at about 40 MB/sec. Denis On 02/21/2013 04:26 PM, Alexander Nyßen wrote: Denis, when trying to run my promotion script (in order to prepare the GEF 3.8.2 release), I run into the problem that file permissions do not seem to be properly restored on /shared, i.e. I am for instance not allowed to access /shared/jobs/gef-maintenance. Cheers Alexander Am 21.02.2013 um 22:21 schrieb Alexander Nyßen alexander.nys...@itemis.de mailto:alexander.nys...@itemis.de: I still can't access hudson.eclipse.org http://hudson.eclipse.org/... Cheers Alexander Am 21.02.2013 um 20:17 schrieb Denis Roy denis@eclipse.org mailto:denis@eclipse.org: build.eclipse.org http://build.eclipse.org/ is back online, and /shared is being restored. Apologies for the long delay. Denis On 02/21/2013 01:50 PM, Dennis Hübner wrote: Am 21.02.2013 um 17:45 schrieb Denis Roy: FWIW, the failed hard drive in /shared is an almost 9-year-old IBM piece that has been taking a beating 24/7. Quality iron right there, folks. Sounds like binford 3000 hard drive. hr hr hr hr. :) Regards, Dennis Hübner Xtext Commiter / Build Engineer ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet!
Simrel is a composite repo, isn't it ? So what about simply adding 1 branch to the composite which contains egit-2.3.1 and then respinnnig the packages ? That shouldn't take more than the week-end , even including all mirroring ? I sympathize with Alexander (GEF) and Fred (m2e), but IMO any risk should be avoided at this time ... I'm sure the PC will make a good decision how to proceed , based on technical feasibility and risk. Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M Williams Sent: Friday, February 22, 2013 3:15 PM To: Cross project issues Subject: [cross-project-issues-dev] Wait ... don't release yet! I'm obviously a little late with my Wait message, but given the data damaging bug reported by EGit, We need to think this through and come up with an alternative plan. All those plans would involve not releasing today. I'll call for an Emergency meeting of the Planning Council today at 1:00 PM Eastern to discuss possible approaches, solutions, and actions required. Off hand, a complete respin cycle would take at least a week, maybe two, but there might be ways to simply remove EGit, putting it back at its SR1 level, producing that better known quantity, and letting EGit follow their own release schedule, as they have been. Sorry for the late Wait notice. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet!
2013/2/22 Denis Roy denis@eclipse.org Off hand, a complete respin cycle would take at least a week, maybe two, but there might be ways to simply remove EGit, putting it back at its SR1 level, producing that better known quantity, and letting EGit follow their own release schedule, as they have been. This may be a naïve question, but if we have the ability to substitute eGit for an older version, can't we substitute eGit for a fixed version? yes, I would prefer this option to go forward and use 2.3.1 instead of going back to EGit 2.1 which was included in SR1. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
After some painful conversation with the Planning Council members, the conclusion was to delay the release 1 week, but not do a full respin, to only revert the EGit contribution. The plan is to redo the common repository and EPP packages, with the EGit contribution reverted to what it was in SR1, which I believe is identical to what it was in RC3. There are a few technical tricks I can try to accomplish this, so all other projects do not have to do any re-work ... just wait until Friday 3/1, before making your releases visible. It was not a easy decision, and arguments made for/against several alternatives, but ended up concluding that reverting seemed to be safest and least amount of re-work. We recognize that many users will be missing out on the new features and bug fixes contained in the newer EGit versions ... and we know the EGit committers have been working hard to improve EGit, which is much appreciated ... but we felt like the community has come to expect the EPP Package Service Releases and common update repo to be rock solid. We feared that respining with even the latest 2.3.1 version (instead of 2.3.0, which has the data-damaging bug) still carried risk associated with 'last minute' changes; that it too might have some bad bugs that simply have not been discovered yet. Unlikely, but, some risk. End-users who are willing too, can always install from EGit's own repository, and hopefully can improve the incremental contribution process for Kepler, which enables more early testing, with a steady ramp down of small changes. The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Apologies for the week delay, I'll keep you updated as Markus and I make progress on our fall-back efforts. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
I hate to throw a stick in the spokes, but what happens if another project in the aggregate repository already has a min dependency on EGit 2.2 or even 2.3? - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn Sent: Friday, February 22, 2013 12:15 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 2013/2/22 David M Williams david_willi...@us.ibm.com After some painful conversation with the Planning Council members, the conclusion was to delay the release 1 week, but not do a full respin, to only revert the EGit contribution. The plan is to redo the common repository and EPP packages, with the EGit contribution reverted to what it was in SR1, which I believe is identical to what it was in RC3. There are a few technical tricks I can try to accomplish this, so all other projects do not have to do any re-work ... just wait until Friday 3/1, before making your releases visible. no, SR2 RC3 contains EGit 2.2.0 [1] which was released in December and SR1 contains EGit 2.1.0 I'd prefer if you could rollback to 2.2.0 but if the planning council decided otherwise be it like that. [1] https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Juno_maintenance https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Juno_maintenanceid=e5209e06bfbe2284a96b1ce357b9fcd1053072d1 id=e5209e06bfbe2284a96b1ce357b9fcd1053072d1 -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
Since the new version of EGit was only introduced in RC3, that could only happen if someone changed their minimum dependency on EGit in their RC4 contribution. That seems unlikely but projects should speak up if they have that constraint. Markus mentioned the only project downstream from EGit was WindowBuilder so it looks like at least for the EPP packages we should be fine. To be clear on what versions of EGit appeared in which Juno build, it looks like the following (which doesn't match what we thought in the call today): Juno SR0 - EGit 2.0 Juno SR1 - EGit 2.1 Juno SR2 RC1: - EGit 2.1 Juno SR2 RC2: - EGit 2.1 Juno SR2 RC3: - EGit 2.2 Juno SR2 RC4: - EGit 2.3 Matthias please correct if that's wrong. John From: Konstantin Komissarchik konstantin.komissarc...@oracle.com To: 'Cross project issues' cross-project-issues-dev@eclipse.org, Date: 02/22/2013 03:26 PM Subject:Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 Sent by:cross-project-issues-dev-boun...@eclipse.org I hate to throw a stick in the spokes, but what happens if another project in the aggregate repository already has a min dependency on EGit 2.2 or even 2.3? - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [ mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn Sent: Friday, February 22, 2013 12:15 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 2013/2/22 David M Williams david_willi...@us.ibm.com After some painful conversation with the Planning Council members, the conclusion was to delay the release 1 week, but not do a full respin, to only revert the EGit contribution. The plan is to redo the common repository and EPP packages, with the EGit contribution reverted to what it was in SR1, which I believe is identical to what it was in RC3. There are a few technical tricks I can try to accomplish this, so all other projects do not have to do any re-work ... just wait until Friday 3/1, before making your releases visible. no, SR2 RC3 contains EGit 2.2.0 [1] which was released in December and SR1 contains EGit 2.1.0 I'd prefer if you could rollback to 2.2.0 but if the planning council decided otherwise be it like that. [1] https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Juno_maintenanceid=e5209e06bfbe2284a96b1ce357b9fcd1053072d1 -- Matthias___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
The only way to be safe is to re-run the aggregation build after the roll-back, regardless of whether the rollback is to 2.1 or 2.2. That will flush out any issues with dependency. Then, of course, we need a contingency for what happens if aggregation fails (there is a dependency). In some ways substituting 2.3.1 is easier and safer. like at least for the EPP packages we should be fine. We need to ensure that the entire release repository is unaffected by the rollback, not just the portions used for EPP. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne Sent: Friday, February 22, 2013 1:44 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 Since the new version of EGit was only introduced in RC3, that could only happen if someone changed their minimum dependency on EGit in their RC4 contribution. That seems unlikely but projects should speak up if they have that constraint. Markus mentioned the only project downstream from EGit was WindowBuilder so it looks like at least for the EPP packages we should be fine. To be clear on what versions of EGit appeared in which Juno build, it looks like the following (which doesn't match what we thought in the call today): Juno SR0 - EGit 2.0 Juno SR1 - EGit 2.1 Juno SR2 RC1: - EGit 2.1 Juno SR2 RC2: - EGit 2.1 Juno SR2 RC3: - EGit 2.2 Juno SR2 RC4: - EGit 2.3 Matthias please correct if that's wrong. John From:Konstantin Komissarchik konstantin.komissarc...@oracle.com To:'Cross project issues' cross-project-issues-dev@eclipse.org, Date:02/22/2013 03:26 PM Subject:Re: [cross-project-issues-dev] Wait ... don't release yet! ...delay one week, Friday 3/1 Sent by:cross-project-issues-dev-boun...@eclipse.org _ I hate to throw a stick in the spokes, but what happens if another project in the aggregate repository already has a min dependency on EGit 2.2 or even 2.3? - Konstantin From: 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 Matthias Sohn Sent: Friday, February 22, 2013 12:15 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 2013/2/22 David M Williams david_willi...@us.ibm.com After some painful conversation with the Planning Council members, the conclusion was to delay the release 1 week, but not do a full respin, to only revert the EGit contribution. The plan is to redo the common repository and EPP packages, with the EGit contribution reverted to what it was in SR1, which I believe is identical to what it was in RC3. There are a few technical tricks I can try to accomplish this, so all other projects do not have to do any re-work ... just wait until Friday 3/1, before making your releases visible. no, SR2 RC3 contains EGit 2.2.0 [1] which was released in December and SR1 contains EGit 2.1.0 I'd prefer if you could rollback to 2.2.0 but if the planning council decided otherwise be it like that. [1] https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Juno _maintenance https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Jun o_maintenanceid=e5209e06bfbe2284a96b1ce357b9fcd1053072d1 id=e5209e06bfbe2284a96b1ce357b9fcd1053072d1 -- Matthias___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Hmm, I am not sure whether I like that recommendation. GEF's release policy has always been easily traceable for all our clients, and with respect to our own update sites there is indeed no problem involved: we have released 3.8.0 and 3.8.1 on the GEF's releases update site properly and we intended do the same with 3.8.2 (which is the intended release for Juno SR2). Because of a missing upper version limit in the gef.b3aggrcon file it happened that GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) and accordingly 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles). Leaving 3.9.0M5 within the SR2 release repo is one thing (I can understand the councils decision, even if I would have liked it to be otherwise), but I don't like that this is going to affect all our future releases as well. Having said so, I would propose that with Kepler we will continue exactly as planned, i.e. ship our intended 3.9.0 release. All our bundles and features are properly equipped with qualifiers, so there should be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be the only places that reflect the above mentioned inconsistency and from Kepler on, everything would be fine again (and we will not have to explain, where we lost our 3.9.0 release). Concerning the GEF releases site, I would like to go for the intended 3.8.2 release there, so clients can consume it from there if they want to, while the 3.9.0M5 is also available from our milestones site. Cheers Alexander Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 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, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
Kosta has a very good point here: moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900mailto:moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900 unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10 'required.*git.*2\.3' | less unit id='org.eclipse.mylyn.github.core' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.github.core' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.mylyn.github.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.op' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.egit.mylyn.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.synchronize' range='[2.3.0,2.4.0)'/ That should be all dependencies onto egit-2.3. I think that egit.mylyn.ui comes from egit itself, but where does the mylyn github feature actually come from ? Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Konstantin Komissarchik Sent: Friday, February 22, 2013 9:24 PM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 I hate to throw a stick in the spokes, but what happens if another project in the aggregate repository already has a min dependency on EGit 2.2 or even 2.3? - Konstantin From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn Sent: Friday, February 22, 2013 12:15 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 2013/2/22 David M Williams david_willi...@us.ibm.commailto:david_willi...@us.ibm.com After some painful conversation with the Planning Council members, the conclusion was to delay the release 1 week, but not do a full respin, to only revert the EGit contribution. The plan is to redo the common repository and EPP packages, with the EGit contribution reverted to what it was in SR1, which I believe is identical to what it was in RC3. There are a few technical tricks I can try to accomplish this, so all other projects do not have to do any re-work ... just wait until Friday 3/1, before making your releases visible. no, SR2 RC3 contains EGit 2.2.0 [1] which was released in December and SR1 contains EGit 2.1.0 I'd prefer if you could rollback to 2.2.0 but if the planning council decided otherwise be it like that. [1] https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Juno_maintenanceid=e5209e06bfbe2284a96b1ce357b9fcd1053072d1 -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
2013/2/22 Oberhuber, Martin martin.oberhu...@windriver.com Kosta has a very good point here: ** ** moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900 unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10 'required.*git.*2\.3' | less ** ** unit id='org.eclipse.mylyn.github.core' version='2.3.0.201302130906'* *** required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.github.core' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.mylyn.github.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.op' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.egit.mylyn.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.synchronize' range='[2.3.0,2.4.0)'/ ** ** That should be all dependencies onto egit-2.3. I think that egit.mylyn.ui comes from egit itself, but where does the mylyn github feature actually come from ? yes, egit.mylyn.ui is egit's mylyn integration and comes with egit mylyn github feature is the Mylyn GitHub connector which is part of the EGit contribution since it's developed in the EGit project. So if the EGit contribution is rolled back to SR1 this would include rolling back the Mylyn GitHub connector to 2.1, same holds true for 2.2.0 since all these features come in the same egit.b3aggrcon file. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
Thanks Matthias – So then in my understanding there is no contribution in Simrel outside egit itself, that would require egit-2.3 and thus the rollback should be fine. Using 2.2 seems preferable to me, to get the fix for bug 391377 that Chuck Bridgham has mentioned. Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn Sent: Friday, February 22, 2013 11:34 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 2013/2/22 Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Kosta has a very good point here: moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900mailto:moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900 unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10 'required.*git.*2\.3' | less unit id='org.eclipse.mylyn.github.core' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.github.core' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.mylyn.github.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.op' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.egit.mylyn.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.synchronize' range='[2.3.0,2.4.0)'/ That should be all dependencies onto egit-2.3. I think that egit.mylyn.ui comes from egit itself, but where does the mylyn github feature actually come from ? yes, egit.mylyn.ui is egit's mylyn integration and comes with egit mylyn github feature is the Mylyn GitHub connector which is part of the EGit contribution since it's developed in the EGit project. So if the EGit contribution is rolled back to SR1 this would include rolling back the Mylyn GitHub connector to 2.1, same holds true for 2.2.0 since all these features come in the same egit.b3aggrcon file. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] GEF Version Numbers
If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen alexander.nys...@itemis.de wrote: The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Hmm, I am not sure whether I like that recommendation. GEF's release policy has always been easily traceable for all our clients, and with respect to our own update sites there is indeed no problem involved: we have released 3.8.0 and 3.8.1 on the GEF's releases update site properly and we intended do the same with 3.8.2 (which is the intended release for Juno SR2). Because of a missing upper version limit in the gef.b3aggrcon file it happened that GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) and accordingly 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles). Leaving 3.9.0M5 within the SR2 release repo is one thing (I can understand the councils decision, even if I would have liked it to be otherwise), but I don't like that this is going to affect all our future releases as well. Having said so, I would propose that with Kepler we will continue exactly as planned, i.e. ship our intended 3.9.0 release. All our bundles and features are properly equipped with qualifiers, so there should be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be the only places that reflect the above mentioned inconsistency and from Kepler on, everything would be fine again (and we will not have to explain, where we lost our 3.9.0 release). Concerning the GEF releases site, I would like to go for the intended 3.8.2 release there, so clients can consume it from there if they want to, while the 3.9.0M5 is also available from our milestones site. Cheers Alexander Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 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, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] GEF Version Numbers
Frankly its rather scary that SR2 will run on a milestone build of GEF. How much testing was there on this milestone to assure fitness for SR2? I know that I, along with others how build upon GEF, would rest easier if the GEF issue was also resolved in the respin. This is the last Juno service release. Lets get this right, even if it takes a bit longer. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Friday, February 22, 2013 2:50 PM To: Cross project issues Subject: [cross-project-issues-dev] GEF Version Numbers If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen alexander.nys...@itemis.de wrote: The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Hmm, I am not sure whether I like that recommendation. GEF's release policy has always been easily traceable for all our clients, and with respect to our own update sites there is indeed no problem involved: we have released 3.8.0 and 3.8.1 on the GEF's releases update site properly and we intended do the same with 3.8.2 (which is the intended release for Juno SR2). Because of a missing upper version limit in the gef.b3aggrcon file it happened that GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) and accordingly 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles). Leaving 3.9.0M5 within the SR2 release repo is one thing (I can understand the councils decision, even if I would have liked it to be otherwise), but I don't like that this is going to affect all our future releases as well. Having said so, I would propose that with Kepler we will continue exactly as planned, i.e. ship our intended 3.9.0 release. All our bundles and features are properly equipped with qualifiers, so there should be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be the only places that reflect the above mentioned inconsistency and from Kepler on, everything would be fine again (and we will not have to explain, where we lost our 3.9.0 release). Concerning the GEF releases site, I would like to go for the intended 3.8.2 release there, so clients can consume it from there if they want to, while the 3.9.0M5 is also available from our milestones site. Cheers Alexander Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 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, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
2013/2/22 Oberhuber, Martin martin.oberhu...@windriver.com Thanks Matthias – ** ** So then in my understanding there is no contribution in Simrel outside egit itself, that would require egit-2.3 and thus the rollback should be fine. Using 2.2 seems preferable to me, to get the fix for bug 391377 that Chuck Bridgham has mentioned. +1 -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
David can correct if I'm wrong here. But the decision was to actually remove Egit from the SR2 repo resulting in the Egit from SR1 getting picked up instead. Egit 2.2 wasn't considered. It's a pretty troubling situation. The community shouldn't be taking this lightly. Sent from my BlackBerry 10 smartphone. From: Oberhuber, Martin Sent: Friday, February 22, 2013 5:40 PM To: Cross project issues Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 Thanks Matthias – So then in my understanding there is no contribution in Simrel outside egit itself, that would require egit-2.3 and thus the rollback should be fine. Using 2.2 seems preferable to me, to get the fix for bug 391377 that Chuck Bridgham has mentioned. Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn Sent: Friday, February 22, 2013 11:34 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1 2013/2/22 Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Kosta has a very good point here: moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900mailto:moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900 unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10 'required.*git.*2\.3' | less unit id='org.eclipse.mylyn.github.core' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.github.core' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.mylyn.github.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.op' range='[2.3.0,2.4.0)'/ […] unit id='org.eclipse.egit.mylyn.ui' version='2.3.0.201302130906' required namespace='java.package' name='org.eclipse.egit.core' range='[2.3.0,2.4.0)'/ required namespace='java.package' name='org.eclipse.egit.core.synchronize' range='[2.3.0,2.4.0)'/ That should be all dependencies onto egit-2.3. I think that egit.mylyn.ui comes from egit itself, but where does the mylyn github feature actually come from ? yes, egit.mylyn.ui is egit's mylyn integration and comes with egit mylyn github feature is the Mylyn GitHub connector which is part of the EGit contribution since it's developed in the EGit project. So if the EGit contribution is rolled back to SR1 this would include rolling back the Mylyn GitHub connector to 2.1, same holds true for 2.2.0 since all these features come in the same egit.b3aggrcon file. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] GEF Version Numbers
If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that seams, that ship already sailed. Sent from my BlackBerry 10 smartphone. From: Konstantin Komissarchik Sent: Friday, February 22, 2013 5:55 PM To: 'Cross project issues' Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Version Numbers Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How much testing was there on this milestone to assure fitness for SR2? I know that I, along with others how build upon GEF, would rest easier if the GEF issue was also resolved in the respin. This is the last Juno service release. Let’s get this right, even if it takes a bit longer. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Friday, February 22, 2013 2:50 PM To: Cross project issues Subject: [cross-project-issues-dev] GEF Version Numbers If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen alexander.nys...@itemis.demailto:alexander.nys...@itemis.de wrote: The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Hmm, I am not sure whether I like that recommendation. GEF's release policy has always been easily traceable for all our clients, and with respect to our own update sites there is indeed no problem involved: we have released 3.8.0 and 3.8.1 on the GEF's releases update site properly and we intended do the same with 3.8.2 (which is the intended release for Juno SR2). Because of a missing upper version limit in the gef.b3aggrcon file it happened that GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) and accordingly 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles). Leaving 3.9.0M5 within the SR2 release repo is one thing (I can understand the councils decision, even if I would have liked it to be otherwise), but I don't like that this is going to affect all our future releases as well. Having said so, I would propose that with Kepler we will continue exactly as planned, i.e. ship our intended 3.9.0 release. All our bundles and features are properly equipped with qualifiers, so there should be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be the only places that reflect the above mentioned inconsistency and from Kepler on, everything would be fine again (and we will not have to explain, where we lost our 3.9.0 release). Concerning the GEF releases site, I would like to go for the intended 3.8.2 release there, so clients can consume it from there if they want to, while the 3.9.0M5 is also available from our milestones site. Cheers Alexander Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nys...@itemis.demailto: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, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource
Re: [cross-project-issues-dev] GEF Version Numbers
Alexander Nyßen wrote: GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) [snip] 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles) The situation in SR2 is far more severe than what happened in SR1. If SR2 respin is done to pick up the correct GEF 3.8.2 release, then users with GEF installed from SR1 repo will not be able to upgrade GEF, but at least no one will be running with pre-release code. Pick your poison. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Friday, February 22, 2013 3:32 PM To: cross-project-issues-dev@eclipse.org; 'Cross project issues' Subject: Re: [cross-project-issues-dev] GEF Version Numbers If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that seams, that ship already sailed. Sent from my BlackBerry 10 smartphone. From: Konstantin Komissarchik Sent: Friday, February 22, 2013 5:55 PM To: 'Cross project issues' Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Version Numbers Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How much testing was there on this milestone to assure fitness for SR2? I know that I, along with others how build upon GEF, would rest easier if the GEF issue was also resolved in the respin. This is the last Juno service release. Let’s get this right, even if it takes a bit longer. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Friday, February 22, 2013 2:50 PM To: Cross project issues Subject: [cross-project-issues-dev] GEF Version Numbers If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen alexander.nys...@itemis.de wrote: The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update site, exactly, since part of the damage already exists in SR1. We recommend to them to make their Kepler version be GEF 3.10, since various Juno versions will have some 3.9 and some 3.8; the differences in code are relatively minor, as I understand it, with the version change being the worst, and some adopters will have to work-around that, but it is feasible to live with it. Hmm, I am not sure whether I like that recommendation. GEF's release policy has always been easily traceable for all our clients, and with respect to our own update sites there is indeed no problem involved: we have released 3.8.0 and 3.8.1 on the GEF's releases update site properly and we intended do the same with 3.8.2 (which is the intended release for Juno SR2). Because of a missing upper version limit in the gef.b3aggrcon file it happened that GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) and accordingly 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles). Leaving 3.9.0M5 within the SR2 release repo is one thing (I can understand the councils decision, even if I would have liked it to be otherwise), but I don't like that this is going to affect all our future releases as well. Having said so, I would propose that with Kepler we will continue exactly as planned, i.e. ship our intended 3.9.0 release. All our bundles and features are properly equipped with qualifiers, so there should be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be the only places that reflect the above mentioned inconsistency and from Kepler on, everything would be fine again (and we will not have to explain, where we lost our 3.9.0 release). Concerning the GEF releases site, I would like to go for
Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1
2013/2/23 Doug Schaefer dschae...@qnx.com David can correct if I'm wrong here. But the decision was to actually remove Egit from the SR2 repo resulting in the Egit from SR1 getting picked up instead. Egit 2.2 wasn't considered. I didn't know that it was decided to remove egit from SR2 and didn't come to the idea that this is a smart way to use the SR1 version which is still in the composite repository It's a pretty troubling situation. The community shouldn't be taking this lightly. I don't take this lightly -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] GEF Version Numbers
Hi Surely we must lose GEF 3.9.0 M5, so we must respin to pick up 3.8.2 that must be reversioned as 3.9.0 to succeed 3.9.0M1 in SR1? Then 3.10.0 for Kepler. [When this is all over, can we have a clearer policy on maintenance releases being maintenance releases, with some aggrcon tooling that diagnoses maintenance version consistency? Seems like this could have avoided both the EGIT and GEF problems.] Regards Ed Willink On 22/02/2013 23:41, Konstantin Komissarchik wrote: Alexander Nyßen wrote: GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) [snip] 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles) The situation in SR2 is far more severe than what happened in SR1. If SR2 respin is done to pick up the correct GEF 3.8.2 release, then users with GEF installed from SR1 repo will not be able to upgrade GEF, but at least no one will be running with pre-release code. Pick your poison. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Friday, February 22, 2013 3:32 PM To: cross-project-issues-dev@eclipse.org; 'Cross project issues' Subject: Re: [cross-project-issues-dev] GEF Version Numbers If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that seams, that ship already sailed. Sent from my BlackBerry 10 smartphone. From: Konstantin Komissarchik Sent: Friday, February 22, 2013 5:55 PM To: 'Cross project issues' Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Version Numbers Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How much testing was there on this milestone to assure fitness for SR2? I know that I, along with others how build upon GEF, would rest easier if the GEF issue was also resolved in the respin. This is the last Juno service release. Let’s get this right, even if it takes a bit longer. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Friday, February 22, 2013 2:50 PM To: Cross project issues Subject: [cross-project-issues-dev] GEF Version Numbers If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1
Re: [cross-project-issues-dev] GEF Version Numbers
The 3.9.0M1 being included in SR1 seems to be an unchanged 3.8.0 with respect to bundles (I assume the branches had not diverged at this point), and only the feature versions increased to 3.9.0 (I will cross-check that again, but the bundles should just have different qualifiers w.r.t. the 3.8.1 versions). 3.9.0M5 actually does not contain many changes either. I intended to address a couple of issues for M6, but I did not have the chance to contribute much to it up to now (Matthias and I have spent work on GEF4), so there is actually just three changes involved: 1) https://bugs.eclipse.org/bugs/show_bug.cgi?id=388697 Changed the visibility of a member 2) https://bugs.eclipse.org/bugs/show_bug.cgi?id=394137 Introduced a new doc bundle for Zest 3) https://bugs.eclipse.org/bugs/show_bug.cgi?id=395872 Fixed the ICU dependencies Fear about using untested bundles therefore is rather baseless. However, it would be nice if we can get this right in the final SR2 repo, as this will remain in place. Is there no chance we can remove GEF 3.9.0M1 from the composite repo and include the intended 3.8.2 now into a respinned SR2? The 3.8.1 has been released on our project releases site, so clients could still consume it from there. Of course this would mean a one-time adoption, but after that things would be ok. Cheers Alexander Am 23.02.2013 um 08:06 schrieb Ed Willink e...@willink.me.uk: Hi Surely we must lose GEF 3.9.0 M5, so we must respin to pick up 3.8.2 that must be reversioned as 3.9.0 to succeed 3.9.0M1 in SR1? Then 3.10.0 for Kepler. [When this is all over, can we have a clearer policy on maintenance releases being maintenance releases, with some aggrcon tooling that diagnoses maintenance version consistency? Seems like this could have avoided both the EGIT and GEF problems.] Regards Ed Willink On 22/02/2013 23:41, Konstantin Komissarchik wrote: Alexander Nyßen wrote: GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - still contained the 3.8.1 bundles, only the feature versions were incremented at that time) [snip] 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 bundles) The situation in SR2 is far more severe than what happened in SR1. If SR2 respin is done to pick up the correct GEF 3.8.2 release, then users with GEF installed from SR1 repo will not be able to upgrade GEF, but at least no one will be running with pre-release code. Pick your poison. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Friday, February 22, 2013 3:32 PM To: cross-project-issues-dev@eclipse.org; 'Cross project issues' Subject: Re: [cross-project-issues-dev] GEF Version Numbers If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that seams, that ship already sailed. Sent from my BlackBerry 10 smartphone. From: Konstantin Komissarchik Sent: Friday, February 22, 2013 5:55 PM To: 'Cross project issues' Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] GEF Version Numbers Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How much testing was there on this milestone to assure fitness for SR2? I know that I, along with others how build upon GEF, would rest easier if the GEF issue was also resolved in the respin. This is the last Juno service release. Let’s get this right, even if it takes a bit longer. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Friday, February 22, 2013 2:50 PM To: Cross project issues Subject: [cross-project-issues-dev] GEF Version Numbers If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?). I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen alexander.nys...@itemis.de wrote: The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug that could be addressed by the project's own update repo and hot fix process. The GEF issue is more complicated, can not be fixed by their own update
