Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository

So it looks like it might be best to not use a composite repository but to specify exactly the one I want to contribute from. I'll also look at the versionRange specification.

Is there any way for me to test what will get picked up by the aggregator without actually running the aggregation?

-- David Dykstal,  Architect - Rational Developer for Power Systems



From:        David M Williams/Raleigh/IBM@IBMUS
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        01/17/2013 12:44 PM
Subject:        Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




What versions were you trying to contribute? I notice your Juno_maintenance version and master version point to different repositories, but each specify the same version of features ... there's nothing wrong with that! ... but, just wondering if that's what you intended?

Just going by the file system, I see you specified
org.eclipse.rse versionRange="3.4.0"
and what's on the ../releases/maintenance file system is
org.eclipse.rse_3.4.1.201209191030-7L7IFBY83omx__z0RFpKdWB-r5MS

but you have a more recent version in
..../3.4milestones/SR2_RC1a/features/org.eclipse.rse_3.4.1.201301071106.jar


There is a couple of ways the aggregator (actually p2) could get the "wrong" version. It is basically just looking for a solution "that satisfies all the constrains". And yes it will try to 'get the highest version' but a) not sure that's guaranteed 100% and (more likely) someone else could say "I want exactly version of XYZ" in which case p2 might well be able to satisfy their requirement, with your "loose" requirement of one repository, that has lots of versions in it, and the only thing you specify is 'higher than 3.4.0'.


All of that leads me to my point ... I always recommend people specify _exactly_ what they want in the versionRange attribute, such as one example I saw as

versionRange
="1.6.0.v20120328-0001-67T-95GFz05DNIrNLOSNK_NPj507"

OR, often easier, to me, is to specify a very specific repo that has only one version of that you want to contribute, such as for you ...


.../tm/updates/3.4milestones/SR2_RC1a


(If that was the one you wanted).


Occasionally this might lead to "early warnings", such as the aggregator (p2) will complain "so and so wants exactly version XYZ but was not found" and then everyone knows ... but, without specific constraints, p2 is doing its job of finding "a solution". For builds, you normally want to be sure they are exact, and repeatable.


Oh, and there are probably many less interesting things that could be going wrong :) ... but, that's the basics.


HTH






From:        
David Dykstal/Rochester/IBM@IBMUS
To:        
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        
01/17/2013 12:14 PM
Subject:        
Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx




I agree. Warmups are good.


I really did mean /tm/updates/3.4milestones. I could have created one specifically for SR2, but we have been storing our milestone builds for our service releases in the directory I used. Seemed like the right spot for the repo.


The aggregation editor does show the features existing under "available versions" and I am on the Juno_maintenance branch. Is there some sort of filtering going on that is missing that version?


-- David Dykstal,  Architect - Rational Developer for Power Systems




From:        
David M Williams/Raleigh/IBM@IBMUS
To:        
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        
01/17/2013 10:37 AM
Subject:        
Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx




Well, that's why we do a warmup :)

Did you meant to contribute ...
/tm/updates/3.4 to Juno or ... /tm/updates/3.4milestones?

I see the former in 'master' and later in 'Juno_maintenance'. I can't tell by the names, but often XXMilestones implies something older than XX repository? You need to use the Juno_maintenance branch of  org.eclipse.simrel.builds project.

HTH





From:        
David Dykstal/Rochester/IBM@IBMUS
To:        
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        
01/17/2013 11:19 AM
Subject:        
Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx




It looks like my first attempt at contributing to the aggregation build failed. If I'm reading the reports correctly I see the TM SR1 plugins there rather than the ones from the repository I thought I had contributed. Obviously my understanding of how the contribution files work is incorrect.


Can someone give me a hand here and look at tm.b3aggrcon?


-- David Dykstal,  Architect - Rational Developer for Power Systems




From:        
David M Williams/Raleigh/IBM@IBMUS
To:        
"Cross project issues (cross-project-issues-dev@xxxxxxxxxxx)" <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        
01/17/2013 08:39 AM
Subject:        
[cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx




Sorry, fell asleep last night :) when I should have been sending out this notice.

But, we are done with SR2 RC1 warm-up repo.

Remember its "staging" location is

http://download.eclipse.org/releases/maintenance/

Besides testing that repo, be sure to check the repository reports ... looks like a few regressions for required files, signed jars, etc.

http://build.eclipse.org/simrel/juno/reporeports/

In addition to testing only that single repo, be sure to test it as a "composite", since eventually it will be added to .../releases/juno

as a child repository. See

http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Test_staging_as_a_pseudo_composite
Don't forget to test "update" scenarios (some of which need to wait for EPP repositories to be ready, if they are not already).

Recall that there is no "promotion" of this repo. It will simply be "left alone" for about a week ... until Juno SR2 RC2 +0.

http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#SR2

As a "warm-up", we don't expect this to be a true "release candidate", but please approach RC2, RC3, etc., with the attitude that those will be true "release candidates" suitable for adopter acceptance testing, etc.

Thanks,

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top