[cross-project-issues-dev] Status and Outlook for M6

[David M Williams <david_williams@xxxxxxxxxx>]

Well, we finally got a green build a few
hours ago so that I was able to promote a new 'staging' repository. Those
of you who are "done" should verify it is as you expect. 
And, still 5 hours or so to go before
the deadline, so I expect things to turn our ok.  As always, keep
us informed of any problems. 

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

reports in 

http://build.eclipse.org/simrel/mars/reporeports/index.html

(Still a lot of legal files missing,
still a lot of unsigned jars from BIRT). 

= = = = = = = = = Long Topic  =
= = = = = = = = = =

Issues around "pack200": 

I know many of you had issues revolving
around invalid jars produced by "pack200", probably related to
you changing the VM you build with, to a higher version. And, I know at
least some of you "turned off" packing, for your entire project
build. 
Understandable, given the deadlines
and the mysteries about why it sometimes breaks jars. (Short answer is,
I think, just that there are some rare combinations of byte codes that
reveal bugs in pack200, and that not much improvement has been made in
pack200 for those rare combinations ... but, I do not know for sure how
to tell for all cases ... it could be invalid byte codes? I could be you
are "packing" something that has not been conditioned, or, conditioned
with a different VM with certain parameters set. In general, "conditioning/packing"
something that has already been conditioned, is not good. 
  pre-condition --> sign -->
pack200 is not the same as 
  pre-condition --> pre-condition
--> sign --> pack200
This is similar if not directly related
to "signing" a jar, that has already been signed -- in theory,
it can work ... but, in practice you have to do it "just right"
(so, I advise not to re-sign a bundle, that has already been signed.

I hope everyone, who has "turned
off" packing completely will reserve some time during M7 to turn it
back on for their project's build, and turn it off for only the jars that
have problems. Here's a few current "statistics" that don't speak
too well, of the quality of our repository, from one of the repo reports.


   Check of packed and not
packed bundles.

Mars M6
   Number of jar files 5682
   Number of pack.gz files
3096
   Difference, number of jar
files to check: 2586
   Checked 2586 of 2586.
   Errors found: 883
   
Luna SR2
   Number of jar files 5440
   Number of pack.gz files
3372
   Difference, number of jar
files to check: 2068
   Checked 2068 of 2068.
   Errors found: 467
   

At first I thought those numbers for
Mars looked pretty bad, but then compared to Luna, and see they were not
great But, even compared to "not great", the number of unpacked
jars has nearly doubled in Mars M6. 
I am not sure (did not measure) what
what translates into in terms of "extra bandwidth required" but
if you haven't heard yet, our bandwidth is already pretty full -- so, please
do your part to minimize that. 
See the report for details. 
http://build.eclipse.org/simrel/mars/reporeports/reports/pack200data.txt
It is the "long runs" of jars
from "one name space" that indicates a project has turned it
off completely. 
And, to clarify the above statistics,
not every jar has to be "packed" ... it does not help much, if
the jar file does not contain Java class files, so it is the "errors"
that indicate a jar file with class files, that is not packed. 
The others are presumably "resource
only" jars (or feature.jars, which have no class files.). 
I hope these wordy explanation helps
you understand why it is important, and how you can help keep it from getting
out of control. 

Thanks,