Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
On 12/20/2012 09:53 PM, David M Williams wrote: Normally having two versions wouldn't hurt anything, unless you know there's some API change or something that makes them incompatible Requiring 2 different versions of a feature which contain some singleton bundles (ie that define some extensions or extension points) makes that the 2 projects requiring the feature don't work together. Ie if site includes Dali (which includes EclipseLink x.y.z) and EclipseLink x.y.z+1 and if EclipseLink contains a singleton bundle, it will be most likely impossible to install Dali and EclipseLink x.y.z+1 in the same Eclipse. The inclusion in feature is a really strong coupling. Version is statically chosen at build-time. This is a bad idea if you are project X to include a feature from project Y since you lock yourself and your users' application to the version of Y you decided to include. It's generally a workaround for not requiring users to add multiple sites. Instead, you should: * use require which allows some version range for feature you want to depend on, and * you could ship a copy of the feature of Y you depend on along with features for X in the repository you produce for X. With this, you remove some constraints and one can update version of your dependencies. The fact that the dependency features are provided on the site makes that installation won't require additional sites. @David: maybe we should set up a rule to verify that as part of Simultaneous Release, since these locking because of inclusions is a common reason why some installations/updates fail. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
Hi I just noticed (I wasn't subscribed to the dev list until this morning), the m2e-wtp features are missing from http://download.eclipse.org/releases/staging/ I pushed http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=6ccc7333262b939e27e6bd370007253f3b737af9late on wed. 19th because I didn't have write access to the repo. Unfortunately it seems the build was triggered just before my push :-( I don't expect the aggregator to be rebuilt at this point but can we at least expect/allow m2e-wtp to be part of M5 then? Regards, Fred Bricon -- 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
Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
Yes, you can be part of M5 but suggest you, or anyone else joining after M4, go through the normal exception process. I'm sure no one would object and plenty of support, but ... I don't want to be in the position of giving my own personal exceptions ... or, I might become real popular :) I'm actually more surprised you just now found out about joining this list! :) I'm sure you've seen our main Simultaneous Release Wiki http://wiki.eclipse.org/Kepler With its plan and requirements: http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements and other useful information. Welcome to Kepler! From: Fred Bricon fbri...@gmail.com To: cross-project-issues-dev@eclipse.org, Date: 12/21/2012 05:18 AM Subject:Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 Sent by:cross-project-issues-dev-boun...@eclipse.org Hi I just noticed (I wasn't subscribed to the dev list until this morning), the m2e-wtp features are missing from http://download.eclipse.org/releases/staging/ I pushed http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=6ccc7333262b939e27e6bd370007253f3b737af9 late on wed. 19th because I didn't have write access to the repo. Unfortunately it seems the build was triggered just before my push :-( I don't expect the aggregator to be rebuilt at this point but can we at least expect/allow m2e-wtp to be part of M5 then? Regards, Fred Bricon -- 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 mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
Yes, I happen to know Dali includes specific bundles via their build packaging, but believe they do simple require the version range they need in their bundles' manifest. And, that EclipseLink is not intended to be included in the IDE, but instead as a runtime target. So I felt fairly comfortable all would be ok. Of course, I don't have perfect knowledge of how everyone uses it which is why I asked if there were known problems, or if it was just a matter of having multiple versions in the repo. By the release, we definitely want one version (unless there's a reason to have different ones). From one of our reports in http://build.eclipse.org/simrel/kepler/reporeports/ namely http://build.eclipse.org/simrel/kepler/reporeports/reports/nonUniqueVersions.txt You can see its not just EclipseLink and Dali that need to do a better job of this :) @David: maybe we should set up a rule to verify that as part of Simultaneous Release, since these locking because of inclusions is a common reason why some installations/updates fail. I'm probably missing your point, but we actually ask the opposite of features. We want those to specify exact bundles they require, because that's the only way people can have perfectly reproducible product installs (and builds that depend on features). Of course, we also recommend people minimize use of including other features and instead depend on bundle's prereq ranges getting something that satisfies the range. If by set up a rule to verify ... you mean there's some tests you could contribute to improve the quality of the repo, I'm all for it! Hope I'm close to interpreting you correctly. Thanks for the suggestions, From: Mickael Istria mist...@redhat.com To: cross-project-issues-dev@eclipse.org, Date: 12/21/2012 03:01 AM Subject:Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 Sent by:cross-project-issues-dev-boun...@eclipse.org On 12/20/2012 09:53 PM, David M Williams wrote: Normally having two versions wouldn't hurt anything, unless you know there's some API change or something that makes them incompatible Requiring 2 different versions of a feature which contain some singleton bundles (ie that define some extensions or extension points) makes that the 2 projects requiring the feature don't work together. Ie if site includes Dali (which includes EclipseLink x.y.z) and EclipseLink x.y.z+1 and if EclipseLink contains a singleton bundle, it will be most likely impossible to install Dali and EclipseLink x.y.z+1 in the same Eclipse. The inclusion in feature is a really strong coupling. Version is statically chosen at build-time. This is a bad idea if you are project X to include a feature from project Y since you lock yourself and your users' application to the version of Y you decided to include. It's generally a workaround for not requiring users to add multiple sites. Instead, you should: * use require which allows some version range for feature you want to depend on, and * you could ship a copy of the feature of Y you depend on along with features for X in the repository you produce for X. With this, you remove some constraints and one can update version of your dependencies. The fact that the dependency features are provided on the site makes that installation won't require additional sites. @David: maybe we should set up a rule to verify that as part of Simultaneous Release, since these locking because of inclusions is a common reason why some installations/updates fail. -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets___ 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] Status and outlook for Kepler M4 +3
Hi, I will handle the soa.bpel warning before this evening. Cheers, Vincent. Le 19/12/2012 22:51, David M Williams a crit: It is almost 5 PM (Eastern) and not heard anyone ask for "wait" ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the "cleanup" next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, -- Vincent Zurczak Phone: +33 (0) 6 40 28 86 57 Linagora: www.linagora.com ___ 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] Status and outlook for Kepler M4 +3
Done. However, I made a Git merge. I just hope I did not break anything. :| Vincent. Le 20/12/2012 15:05, Vincent Zurczak a crit: Hi, I will handle the soa.bpel warning before this evening. Cheers, Vincent. Le 19/12/2012 22:51, David M Williams a crit: It is almost 5 PM (Eastern) and not heard anyone ask for "wait" ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the "cleanup" next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, -- Vincent Zurczak Phone: +33 (0) 6 40 28 86 57 Linagora: www.linagora.com ___ 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] Status and outlook for Kepler M4 +3
Thanks Vincent!bob Hi, I will handle the soa.bpel warning before this evening. Cheers, Vincent. Le 19/12/2012 22:51, David M Williams a écrit: It is almost 5 PM (Eastern) and not heard anyone ask for "wait" ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the "cleanup" next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, -- Vincent Zurczak Phone: +33 (0) 6 40 28 86 57 Linagora: www.linagora.com ___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orghttps://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] Status and outlook for Kepler M4 +3
Cool. Does this mean we are ready for Kepler M4? Done. However, I made a Git merge. I just hope I did not break anything. :| Vincent. Le 20/12/2012 15:05, Vincent Zurczak a écrit: Hi, I will handle the soa.bpel warning before this evening. Cheers, Vincent. Le 19/12/2012 22:51, David M Williams a écrit: It is almost 5 PM (Eastern) and not heard anyone ask for "wait" ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the "cleanup" next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, -- Vincent Zurczak Phone: +33 (0) 6 40 28 86 57 Linagora: www.linagora.com ___ 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 listcross-project-issues-dev@eclipse.orghttps://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] Status and outlook for Kepler M4 +3
David, I was certain that I'd already updated EclipseLink, but that was not the case. I double checked this morning on a whim due to this thread, and discovered the issue. You are using our M5, but our build was still set to M4. That would leave two sets of jars in the aggregation. I've just submitted the new build file. I apologize for the mix-up. -Eric ___ 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] Status and outlook for Kepler M4 +3
I'm a bit confused, but in any case would need more justification to do a rebuild, this late. What impact to users is there? Can they get your correct M4 from your own repo? Is there a work around? Does it effect EPP packages? When I look for Eclipse link in .../releases/staging, I do see the same thing as in .../releases/kepler; EclipseLink Target Components 2.5.0.v20121016-ab08992 So, I think you are saying that's your M3 level? But your note, and your commit to get mention M5: update Kepler contrib to EclipseLink M5. We are still on M4, if that's a point of confusion. But in any case, can you make an argument why this would be blocking. FYI, we've not strict on dates just for sake of being strict (though, that is a good reason :) ... but the process of doing a rebuild is itself risky ... others might have changed something, intentional or not ... so introduces uncertainty and a lot of re-work for many. So, if your users can get what they need from your project's repo, I'd prefer to go that route. Thanks, From: Eric Gwin eric.g...@oracle.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 12/20/2012 11:34 AM Subject:Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 Sent by:cross-project-issues-dev-boun...@eclipse.org David, I was certain that I'd already updated EclipseLink, but that was not the case. I double checked this morning on a whim due to this thread, and discovered the issue. You are using our M5, but our build was still set to M4. That would leave two sets of jars in the aggregation. I've just submitted the new build file. I apologize for the mix-up. -Eric ___ 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] Status and outlook for Kepler M4 +3
This commit, did break aggregation. The reason is you removed the feature from your file, but its still listed in the SOA Development Category. When ever features are added or removed, I recommend using the b3 aggregator editor. It often effects not only your file, but the simrel.b3aggr file, where categories are defined. The validate action will say if the model is still valid and consistent. Both your file, and simrel.b3aggr must to checked in together. Perhaps you did make the change correctly, and simply forgot to check-in the simrel file? But, in any case, we don't need to re-spin now, for a removed feature, since it was disabled anyway, but will have to be fixed before we could aggregate, again. commit e8b21c7ce2d64654edce952cac08c5f608031925 Author: vzurczak vincent.zurc...@petalslink.com Date: Thu Dec 20 15:23:23 2012 +0100 Remove a disabled feature. Signed-off-by: vzurczak vincent.zurc...@petalslink.com From: Vincent Zurczak vincent.zurc...@linagora.com To: cross-project-issues-dev@eclipse.org, Date: 12/20/2012 09:35 AM Subject:Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 Sent by:cross-project-issues-dev-boun...@eclipse.org Done. However, I made a Git merge. I just hope I did not break anything. :| Vincent. Le 20/12/2012 15:05, Vincent Zurczak a écrit : Hi, I will handle the soa.bpel warning before this evening. Cheers, Vincent. Le 19/12/2012 22:51, David M Williams a écrit : It is almost 5 PM (Eastern) and not heard anyone ask for wait ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the cleanup next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, -- Vincent Zurczak Phone: +33 (0) 6 40 28 86 57 Linagora: www.linagora.com ___ 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 image/pngimage/pngimage/pngimage/png STG06729 Description: Binary data STG45220 Description: Binary data STG61102 Description: Binary data STG27331 Description: Binary data ___ 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] Status and outlook for Kepler M4 +3
Le 20/12/2012 18:44, David M Williams a écrit : This commit, did break aggregation. The reason is you removed the feature from your file, but its still listed in the SOA Development Category. When ever features are added or removed, I recommend using the b3 aggregator editor. It often effects not only your file, but the simrel.b3aggr file, where categories are defined. The validate action will say if the model is still valid and consistent. Both your file, and simrel.b3aggr must to checked in together. Perhaps you did make the change correctly, and simply forgot to check-in the simrel file? But, in any case, we don't need to re-spin now, for a removed feature, since it was disabled anyway, but will have to be fixed before we could aggregate, again. Indeed, my mistake. I have just pushed the simrel file too. Thanks, Vincent. commit e8b21c7ce2d64654edce952cac08c5f608031925 Author: vzurczak vincent.zurc...@petalslink.com Date: Thu Dec 20 15:23:23 2012 +0100 Remove a disabled feature. Signed-off-by: vzurczak vincent.zurc...@petalslink.com ___ 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] Status and outlook for Kepler M4 +3
David, No. EclipseLink's M4 was 2.5.0.v20121016-ab08992, it is what was included in the aggregation files. However, Dali is including EclipseLink directly, and they are using M5 (2.5.0.v20121120-ec51fcc). So currently both versions are in the aggregation. When I released our M5 I thought I had updated the aggregation files to reflect the new Milestone. However somehow it never did occur. I probably forgot to push my local change, and later issues caused me to re-clone so the change was lost. In any case, the only issue I'm aware of is the multiple versions of most of our bundles. I'm unaware of any other repercussion. I just thought that if the aggregation was going to be redone, than syncing things up would be in everyone's best interest. Your call however. -Eric On 20/12/2012 12:24 PM, David M Williams wrote: I'm a bit confused, but in any case would need more justification to do a rebuild, this late. What impact to users is there? Can they get your correct M4 from your own repo? Is there a work around? Does it effect EPP packages? When I look for Eclipse link in .../releases/staging, I do see the same thing as in .../releases/kepler; EclipseLink Target Components2.5.0.v20121016-ab08992 So, I think you are saying that's your M3 level? But your note, and your commit to get mention M5: update Kepler contrib to EclipseLink M5. We are still on M4, if that's a point of confusion. But in any case, can you make an argument why this would be blocking. FYI, we've not strict on dates just for sake of being strict (though, that is a good reason :) ... but the process of doing a rebuild is itself risky ... others might have changed something, intentional or not ... so introduces uncertainty and a lot of re-work for many. So, if your users can get what they need from your project's repo, I'd prefer to go that route. Thanks, From: Eric Gwin eric.g...@oracle.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 12/20/2012 11:34 AM Subject: Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 Sent by: cross-project-issues-dev-boun...@eclipse.org -- David, I was certain that I'd already updated EclipseLink, but that was not the case. I double checked this morning on a whim due to this thread, and discovered the issue. You are using our M5, but our build was still set to M4. That would leave two sets of jars in the aggregation. I've just submitted the new build file. I apologize for the mix-up. -Eric ___ 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] Status and outlook for Kepler M4 +3
Eric Gwin eric.g...@oracle.com wrote on 12/20/2012 02:04:11 PM: No. EclipseLink's M4 was 2.5.0.v20121016-ab08992, it is what was included in the aggregation files. However, Dali is including EclipseLink directly, and they are using M5 (2.5.0.v20121120- ec51fcc). So currently both versions are in the aggregation. When I released our M5 I thought I had updated the aggregation files to reflect the new Milestone. However somehow it never did occur. I probably forgot to push my local change, and later issues caused me to re-clone so the change was lost. There is clearly still confusion on dates and milestones. Kepler M5 will be February 8, 2013. See http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule John___ 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] Status and outlook for Kepler M4 +3
It is almost 5 PM (Eastern) and not heard anyone ask for wait ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the cleanup next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, ___ 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] Status and outlook for Kepler M4 +3
Official wait from Sapphire. Should be able to make the contribution in the next hour or so. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M Williams Sent: Wednesday, December 19, 2012 1:51 PM To: Cross project issues (cross-project-issues-dev@eclipse.org) Subject: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 It is almost 5 PM (Eastern) and not heard anyone ask for wait ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the cleanup next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, ___ 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] Status and outlook for Kepler M4 +3
Sapphire contribution is in. From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Konstantin Komissarchik Sent: Wednesday, December 19, 2012 1:54 PM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 Official wait from Sapphire. Should be able to make the contribution in the next hour or so. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M Williams Sent: Wednesday, December 19, 2012 1:51 PM To: Cross project issues (cross-project-issues-dev@eclipse.org) Subject: [cross-project-issues-dev] Status and outlook for Kepler M4 +3 It is almost 5 PM (Eastern) and not heard anyone ask for wait ... though sounded implied by some messages here? I do see that amp is completely disabled (at the repository level): amp.b3aggrcon - org.eclipse.simrel.build These three projects have a feature or two disabled. Not sure if the features are no longer needed/used or if a respin is needed now that others are up to date? dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build If it is a matter of deleting unused one, there is no need to do that today, but would appreciate the cleanup next cycle, just so it is easier for me to tell what's what. I'll wait a few more hours (till 7 PM, Eastern) just to see if there's any stragglers, and if not, turn off the aggregation job until after M4. Thanks all, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
