Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] R build for Galileo SR2


> ... What are the plans to get an R build?
> At this point I'm satisfied with the content of ...


Darn. I was hoping we would not need a new R build. :)

And ... I assume ... you are saying you do need a new one?
For Galileo maintenance?
Probably to get both of the new sat4j bundles?

org.sat4j.core_2.1.1.v20090825.jar
org.sat4j.pb_2.1.1.v20090825.jar

instead of the old

org.sat4j.core_2.1.1.v20090812.jar
org.sat4j.pb_2.1.1.v20090812.jar

Those 13 days made a big difference, eh? :)

I think this time, we probably should not simply take our latest Helios S build, for our Galileo R build.
There's been lots of changes ... some maybe needed? But some might "surprise" some adopting projects?

Below is my detailed analysis, just based on "surface", I did not look at bugzilla to see what was
fixed. In the next few days, if we hear a loud outcry that all the changes are also needed in maintenance,
maybe we'll reconsider, but otherwise, we will be safer to start a maintenance branch of map files, and
require explicit action for someone to get a change into maintenance.

= = = = = =

From taking a 'diff' of latest R build and latest S build (not looking
at how/if files differed, but only which jars are 'new' or 'absent' ...
BUT, which were _similar_ to existing ones.

Old, Only in orbit-R20090825191606

Only in orbit-R20090825191606/eclipse/plugins: javax.servlet_2.5.0.v200806031605.jar
Only in orbit-R20090825191606/eclipse/plugins: org.apache.derby_10.1.2.1_v200803061811.jar
Only in orbit-R20090825191606/eclipse/plugins: org.apache.ws.commons.util_1.0.0.v20081204.jar
Only in orbit-R20090825191606/eclipse/plugins: org.apache.ws.commons.util_1.0.1.v20081204-1018.jar
Only in orbit-R20090825191606/eclipse/plugins: org.sat4j.core_2.1.1.v20090812.jar
Only in orbit-R20090825191606/eclipse/plugins: org.sat4j.pb_2.1.1.v20090812.jar
Only in orbit-R20090825191606/eclipse/plugins: org.slf4j.api_1.5.6.v200903200722.jar

New, Only in orbit-S20091203150826

Only in orbit-S20091203150826/eclipse/plugins: javax.servlet_2.5.0.v200910301333.jar
Only in orbit-S20091203150826/eclipse/plugins: org.apache.derby_10.5.1.1_200912031533.jar
Only in orbit-S20091203150826/eclipse/plugins: org.apache.ws.commons.util_1.0.0.v20091022-1630.jar
Only in orbit-S20091203150826/eclipse/plugins: org.apache.ws.commons.util_1.0.1.v20091022-1635.jar
Only in orbit-S20091203150826/eclipse/plugins: org.sat4j.core_2.1.1.v20090825.jar
Only in orbit-S20091203150826/eclipse/plugins: org.sat4j.pb_2.1.1.v20090825.jar
Only in orbit-S20091203150826/eclipse/plugins: org.slf4j.api_1.5.6.v20090930-0800.jar

How many of those 7 new ones are _required_ for maintenance?

Completely new bundles, in Orbit S build. Could any cause "confusion" with similar/matching bundles
(that previously were contributed to Galileo from individual Projects, not Orbit).

Only in orbit-S20091203150826/eclipse/plugins: com.google.gwt.servlet_1.7.0.v20091020-1225.jar
Only in orbit-S20091203150826/eclipse/plugins: com.google.gwt.user_1.7.0.v20091019-0813.jar
Only in orbit-S20091203150826/eclipse/plugins: javax.inject_1.0.0.v20091030.jar
Only in orbit-S20091203150826/eclipse/plugins: net.miginfocom.layout.swing_3.7.1.v200911230030.jar
Only in orbit-S20091203150826/eclipse/plugins: net.miginfocom.layout.swt_3.7.1.v200911230030.jar
Only in orbit-S20091203150826/eclipse/plugins: net.miginfocom.layout_3.7.1.v200911230030.jar
Only in orbit-S20091203150826/eclipse/plugins: org.kohsuke.args4j_2.0.12.v200910131500.jar
Only in orbit-S20091203150826/eclipse/plugins: org.objectweb.asm_3.2.0.v200909071300.jar

Only in orbit-S20091203150826/eclipse/plugins: org.apache.commons.jxpath_1.3.0.v200911051830.jar
Only in orbit-S20091203150826/eclipse/plugins: org.apache.log4j_1.2.15.v200910021404.jar
Only in orbit-S20091203150826/eclipse/plugins: org.junit_4.7.0.v20091118-1515
Only in orbit-S20091203150826/eclipse/plugins: org.mozilla._javascript__1.7.2.v200909291707.jar



Yes. While 8 of these 12 are completely new and distinct, hence safe,
from looking at ~/downloads/releases/helios, there are 4 similar, previously
existing Galileo versions ... that _might_ cause "confusion" with the more recent versions.

org.apache.commons.jxpath_1.2.0.v20080604-1500.jar
org.apache.log4j_1.2.13.v200903072027.jar
org.junit_3.8.2.v20090203-1005.jar
org.mozilla.rhino_1.7.1.v20090521.jar (same _packages_ as the new org.mozilla._javascript_ bundle)

= = = = = =

What this comes down to is what do Orbit Committers want?
If we have a maintenance branch, how many of these changes should go in
that maintenance branch anyway? I suspect not many? Even if all of them
end up there, that's the safer approach this time.

Given the (short) timing, unless there's the famed outcry mentioned above,
I think next week we should start producing "M builds". Then, on 1/25, promote
that as the R build for projects to use for SR2 maintenance. (Projects could
use the M build for SR2 RC1, then change to R build, for SR2 RC2.)

I think this approach minimizes difference between previous R build (used for SR1)
so minimizes risk ... with fairly small increase in our work :( and some slight
risk of confusing the heck out of everybody :)  While the risk of breaking someone
is not large, its probably better to take the conservative approach.

Other views?


Back to the top