Hi Team,

Following up on the install scenarios.  A wiki page has been created to 
document the install scenario results.  Please take a few minutes to run 
these scenarios and update your results.  Thank you! 
http://wiki.eclipse.org/WTP_Functional_Test_R30_Installs

We're still missing smoktest results from a couple of teams on the final 
Ganymede driver (JPA & JSDT), if you could take a minutes to update. 
Thanks!
http://wiki.eclipse.org/WTP_Smoke_Test_Results_R30_061208


Regards,
Helen Zhang PMPĀ®
Rational Architecture Management Project Management Office 
Eclipse Webtools Platform (WTP) 
IBM Toronto Software Lab | 8200 Warden Ave. | Markham | L6G 1C7 
Email: [EMAIL PROTECTED] | Phone: 905-413-3443 | T/L: 969-3443 



David M Williams <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
06/16/2008 12:20 AM
Please respond to
"General discussion of project-wide or architectural issues." 
<[email protected]>


To
[email protected]
cc

Subject
[wtp-dev] Are we there yet?







Imagine a family on a long, hot summer vacation, with a car full of kids, 
... I feel like that father :) 
  
And, the answer is the same ... "no, we are not there yet, but just a 
little further ... so you can hold it! "  (as my father used to say :) 

But honest, we really are close. Off hand I can think of a few things yet 
to do ... I'm sure Helen will be reminding us of any others. 

1. Verify Bugs. Remember to verify "resolved" bugs, especially those that 
were opened as blockers and criticals! Preferably all 'majors' too ... but 
I personally am not too worried about 'normal' ones (they should be 
verified, of course, but I just mean if you have to prioritize, those 
would be pretty low on the to-do list). 

If you forget what it means to verify a 'dup' bug, and similar, please see 

http://wiki.eclipse.org/WTP_Bugs%2C_Workflow_and_Conventions#The_meaning_and_methods_of_verification
 

  
If it is not obvious, we are at the point that we can not always wait for 
the originator to 'verify' a bug ... so team leads should themselves (at 
least for the blocking/critical ones!). 

2. Triage Bugs. Please make sure all your open critical and blocking 
defects are properly triaged: If you can't reproduce it, resolve it as 
works for me, but if you can confirm it as a bug, and you agree it 
deserves a blocking or critical status, then please explain why it can not 
be fixed right now (before release) and what our plan is to address it 
(either to provide patch, or fix in 3.0.1). 

The PMC will be asked to take a close look at our blocking and critical 
list, on Tuesday, to confirm we all agree we are ready to release, even 
with these blockers and criticals. 

3. Confirm Installs. Please confirm and test all the different install 
methods we now have. Perhaps Helen ... or someone ... can think of an easy 
way to be systematic and document what's been tested? I don't intend each 
team to test all possibilities. Some teams have a more "vested interest" 
in some install paths. And, by "testing" I don't mean to necessarily do a 
full test .... but, install it, inspect plugins, features, (and 
documentation, preferences, help, etc.) and be sure what you would expect 
to be there, really is there, and sanity check a couple of "main path" 
tasks. 

A. JEE Developer IDE. 
Currently, the URL to get the most recent JEE package from is 
http://build.eclipse.org/technology/epp/epp_build/34/download/20080615-0610/index.html
 

but you might check 
http://build.eclipse.org/ganymede/ 
to be sure you are getting the most recent. (if anything is more recent 
that 20080615). 
On Tuesday, the "most recent" URL will be 
http://phoenix.eclipse.org/packages/ 
Which is likely to be the final version, 
to be moved to official release URL, on the release date. 

This is "the fullest" install ... should have everything that is in our 
zips, plus Mylin, plus remote target management. It won't have 
'capabilities', that is a known bug (235089) but you might check other 
preference pages, etc. Also note: this is a an "end-user" package, so 
should be not have source nor JavaDoc. 
This package is the most popular download package from Eclipse, so it's 
important we verify it. 
Windows, and Linux 32 are pretty easy .. and Nick often checks the Mac for 
us, since he's the only Mac user in the group ... that I know of. 
Anyone have a 64 bit system they can verify that install on? 

B. Update sites ... for now, you'll have to add these locations to your 
sites for software updates ... only after release, will the built-in URLs 
point to the right places. 

B1. Ganymede update site 
For now, the best URL to use is 
http://download.eclipse.org/releases/ganymede/staging/ 
(I'm not sure what the exact plan is, but at some point, what is at 
staging is moved to 
http://download.eclipse.org/releases/ganymede/ 
and that will become the official released version 

Using Ganymede update site, you can start with _only_ the Eclipse 
Platform, and pick individual features to install. What ever our features 
need, should be pulled down automatically (no "select required" any 
longer). 

Main install scenarios 
Javascript (only 'platform' is required). 
XML (platform, gef, a few emf pieces and xsd info-set are all required ... 
that is, should also end up in your install). 
Web Developer (as above ... i.e. still no JDT!). 
JEE Developer (requires JDT, and some features from DTP). 

Secondary install scenarios 
There are some "optional" features you can pick (unfortunately, this 
release, most of these 'optional' features are also installed if you 
install the JEE Developer ... a change in behavior from update manager was 
discovered too late to change our feature definitions). But, if you start 
off picking an optional feature, it should pull in anything required. 

B2. Webtools update site 

Similar to Ganymede site, but all pre-reqs must be installed already. 
The URL for now is 
http://download.eclipse.org/webtools/milestones/ 

The main scenario to test here ... the one we have designed for ... is 
that if someone 
installed some webtools stuff from Ganymede, then you can go to the 
Webtools update site to get the matching SDK portion, for those users that 
need the source and JavaDoc. 

(Eventually, the XSL Incubating feature will be here too ... but, haven't 
update for that yet). 

Note: for those of you that haven't seen it yet, the current UI for 
Software Updates has one very different behavior than the old UM UI. (This 
is documented as an issue in bug 224472) If you install something like 
"Web Developer" which also includes XML and JavaScript, the included 
features stay on the "available software" list, as though it was not 
installed (even though it was). The reason for this is to "match" exactly 
what the user choose to install, not what was done "under the covers"). I 
think ... though I haven't tested it myself ... is that this allows for 
improved uninstall behavior (or, at least will in the future). So 
certainly open bugs if you find them, or see things you don't like ... 
but, this final exercise isn't to test or evaluate "Software Updates" UI 
.. it's just to make sure things work with respect to Webtools 
installations. 


Thanks everyone ... just a little further. 

_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev

_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Reply via email to