Re: [cross-project-issues-dev] Planning to make .../releases/kepler be M4 only

[Mickael Istria]

On 12/20/2012 10:20 PM, David M Williams wrote:
Most of you know, that we normally keep 3 milestones in our common 
repository, as a composite.
This works as  long as no one removes a feature or a feature is 
mistakenly "down versioned".


The easiest fix at this point, for common repo is just to make the 
common repo be M4 only
I think it's a good move to put only one version in the repo since 
before, some errors (missing IUs) in Milestone M could have been hidden 
by what's provided in milestone M-1.
Having a single milestone makes the releases/kepler repo much closer 
from what will be the final repo, and it seems more helpful to catch 
possible issues early.


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

Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3

[Eric Gwin]

Sorry about that. Cut and paste error, I didn't notice. Should be fixed now.

As to the separate milestones... yea it can lead to confusion. We try to generate a Milestone for EclipseLink once a 
month and when referring to the SimRel Train contribution can lead to confusion. I try to follow the nomenclature of 
"Kepler M4" vs "EclipseLink M5", so my comments usually say something akin to "Contribution of 
EclipseLink M5 for Kepler M4" Though sometimes it is just "EclipseLink contribution for Kepler M#" and 
the aggregation file specifies the appropriate EclipseLink milestone repo.

If you can think of a better methodology let me know.

Eric

On 20/12/2012 3:53 PM, David M Williams wrote:

Ok, thanks Eric, for letting us know. Neil's told me you kind of have "your 
own" milestones, and then take the closest one to our Simultaneous Milestones ... no 
harm in that, just means we have to communicate carefully.

Normally "having two versions" wouldn't hurt anything, unless you know there's 
some API change or something that makes them incompatible, so I'll assume we are ok, 
unless someone reports an actual problem (and, getting kind of late, even for that :)

You are right, there's no harm doing the update so "in case" we need to respin, 
it would pick up your corrected version, however I still get
Unable to load repository 
p2:http://download.eclipse.org/rt/eclipselink/milestone-updates/2.5.0.v20121120-ec51fcc_M5
so if we did respin right now, we'd be broken.
I think the first problem is there is a space (blank) in both your URL and 
version that should not be there.
But, even if I fix that, then I get:

Cannot complete the install because one or more required items could not be 
found.
Missing requirement: EclipseLink JPA 2.5.0.v20121120-ec51fcc 
(org.eclipse.persistence.jpa.feature.group 2.5.0.v20121120-ec51fcc) requires 
'org.eclipse.persistence.oracle [2.5.0.v20121120-ec51fcc]' but it could not be 
found

InstallableUnit(org.eclipse.persistence.oracle 
[2.5.0.v20121120-ec51fcc,2.5.0.v20121120-ec51fcc]) is required by:
  ValidationSet(main)
Contribution(EclipseLink)
  
MappedRepository(http://download.eclipse.org/rt/eclipselink/milestone-updates/2.5.0.v20121120-ec51fcc_M5)
Feature(org.eclipse.persistence.sdk.feature.group 
2.5.0.v20121120-ec51fcc)
  InstallableUnit(org.eclipse.persistence.jpa.feature.group 
2.5.0.v20121120-ec51fcc)


The b3 aggregator editor can be your friend :)




From: Eric Gwin 
To: Cross project issues ,
Date: 12/20/2012 02:06 PM
Subject: Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
Sent by: cross-project-issues-dev-boun...@eclipse.org
--



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 

[cross-project-issues-dev] Planning to make .../releases/kepler be M4 only

[David M Williams]

Most of you know, that we normally keep 3 milestones in our common 
repository, as a composite. 
This works as  long as no one removes a feature or a feature is mistakenly 
"down versioned". 

But, I have detected a problem with doing that this time. See
Bug 397033 - Acceleo has conflicting dependency in M2, M3, M4 composite 
Kepler repo 

The easiest fix at this point, for common repo is just to make the common 
repo be M4 only, to avoid the "conflicting dependencies", though it might 
be a sign of some other problem with the contribution.  Please comment in 
the bug, if anyone was really looking forward to testing "roll back" or 
"performance" this milestone :) or knows of a better fix (keeping in mind, 
its too late to "fix" the repo it self, just for this). 

With just M4 enabled, I was able to select and "install everything" ... 
but ... did eventually get an error about 
An error occurred while installing the items
session context was:(profile=SDKProfile, 
phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null 
--> [R]org.eclipse.php.core.source 3.1.1.201209101312, 
action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.AddSourceBundleAction).
The artifact file for 
osgi.bundle,org.eclipse.php.core.source,3.1.1.201209101312 was not found.

Not sure if that's reproducible, some contribution is wrong, or a sign 
some mirror is misconfigured, or where it comes from. Just reporting it 
here to encourage all "test early, test often" :) 

 

___
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 M Williams]

Ok, thanks Eric, for letting us know. Neil's told me you kind of have 
"your own" milestones, and then take the closest one to our Simultaneous 
Milestones ... no harm in that, just means we have to communicate 
carefully. 

Normally "having two versions" wouldn't hurt anything, unless you know 
there's some API change or something that makes them incompatible, so I'll 
assume we are ok, unless someone reports an actual problem (and, getting 
kind of late, even for that :) 

You are right, there's no harm doing the update so "in case" we need to 
respin, it would pick up your corrected version, however I still get 
Unable to load repository p2:
http://download.eclipse.org/rt/eclipselink/milestone-updates/ 
2.5.0.v20121120-ec51fcc_M5
so if we did respin right now, we'd be broken. 
I think the first problem is there is a space (blank) in both your URL and 
version that should not be there. 
But, even if I fix that, then I get: 

Cannot complete the install because one or more required items could not 
be found.
Missing requirement: EclipseLink JPA 2.5.0.v20121120-ec51fcc 
(org.eclipse.persistence.jpa.feature.group 2.5.0.v20121120-ec51fcc) 
requires 'org.eclipse.persistence.oracle [2.5.0.v20121120-ec51fcc]' but it 
could not be found

InstallableUnit(org.eclipse.persistence.oracle 
[2.5.0.v20121120-ec51fcc,2.5.0.v20121120-ec51fcc]) is required by:
  ValidationSet(main)
Contribution(EclipseLink)
  MappedRepository(
http://download.eclipse.org/rt/eclipselink/milestone-updates/2.5.0.v20121120-ec51fcc_M5
)
Feature(org.eclipse.persistence.sdk.feature.group 
2.5.0.v20121120-ec51fcc)
  InstallableUnit(org.eclipse.persistence.jpa.feature.group 
2.5.0.v20121120-ec51fcc)


The b3 aggregator editor can be your friend :) 
 



From:   Eric Gwin 
To: Cross project issues , 
Date:   12/20/2012 02:06 PM
Subject:Re: [cross-project-issues-dev] Status and outlook for 
Kepler M4 +3
Sent by:cross-project-issues-dev-boun...@eclipse.org



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

Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3

[John Arthorne]

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

Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3

[Eric Gwin]

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

[David M Williams]

Thanks, now the model validates, but I get a message (when running 
locally) related to the Eclipselink contribution: 

Unable to load repository p2:
http://download.eclipse.org/rt/eclipselink/milestone-updates/ 
2.5.0.v20121120-ec51fcc_M5

Judging from the last couple of letters ("M5") perhaps there is some 
confusion about which milestone we're on? Probably just a naming issue? 

HTH




From:   Vincent Zurczak 
To: cross-project-issues-dev@eclipse.org, 
Date:   12/20/2012 01:14 PM
Subject:Re: [cross-project-issues-dev] Status and outlook for 
Kepler M4 +3
Sent by:cross-project-issues-dev-boun...@eclipse.org



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  
Date:   Thu Dec 20 15:23:23 2012 +0100 

Remove a disabled feature. 
 
Signed-off-by: vzurczak  
___
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

[Vincent Zurczak]

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 
Date:   Thu Dec 20 15:23:23 2012 +0100

Remove a disabled feature.

Signed-off-by: vzurczak 


___
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 M Williams]

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 
Date:   Thu Dec 20 15:23:23 2012 +0100

Remove a disabled feature.
 
Signed-off-by: vzurczak 




From:   Vincent Zurczak 
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

<><><><>

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

[David M Williams]

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

[Eric Gwin]

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

[Bob Brodt]

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

[Bob Brodt]

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

[Vincent Zurczak]

  
  
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

[Vincent Zurczak]

  
  
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