Community
Participate
Working Groups
A new SAT4J is available (v2.3) and we should consume it in p2 when it is available. CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5113 Since we are late in the release cycle we need to decide whether or not to consume this version for Indigo. As discussed in the Equinox meeting, I will run the performance tests on the new JARs and report back with the performance results.
Marking as 3.7 target milestone so we don't lose track.
CQ approved. Libraries approved for reuse.
Here are the average times for running the performance tests on the two different versions of the SAT4J jars. I ran the test suites 4 times for each version of the JAR, and these are the average times for each of the 4 tests within the suites. The new JAR seems to resolve conflicts quicker in most scenarios except the first one, where it is minimally slower. v2.2.0 736 401 712 749 v2.3.0 810 324 397 417
*** Bug 323333 has been marked as a duplicate of this bug. ***
Note the version range in the manifest of the director bundle also needs to be changed in order to handle the new versions.
Created attachment 194639 [details] patch Patch with changes to the director manifest to accept the new SAT4J version as well as getting the SAT4J JARs from the latest Orbit committer i-build. Note this needs to be changed to a more permanent build once one is promoted for RC1.
Kim, I checked the p2 features and they include version 0.0.0 so we don't have to update anything there. Are there any other build-type files that need to be updated for a new version of SAT4J?
org.eclipse.platform.doc.isv\platformOptions.txt also needs to be updated to include path to the new sat4j jars.
Ok thanks, I'll attach a patch. And I'll assume that it also has to be updated for the new ECF that if we release that too since I see references to those JARs in there as well.
Created attachment 194643 [details] patch for javadoc Also includes changes from bug 341290.
Daniel, can you describe the amount of change and types of changes between 2.2. and 2.3? We need to determine the amount of risk for putting in the new JARs this late in the release cycle. From my memory I believe there are some performance improvements as well as the new addition of the #isOptimal APIs. Would you consider moving to v2.3 low-risk? Thanks.
There are numerous changes in Sat4j itself but very few are used by eclipse. The only change that is really hitting Eclipse is the explanation algorithm that has been improved. So I would say that we have few chances to break anything: the code path used by Eclipse has been quite stable for a while. While the explanation time improvement is alone a good reason to include Sat4j 2.3, I think that the addition of the #isOptimal() API will provide us the ability to better debug specific scenarios where Sat4j may not be able to answer optimally (with the new API, we will be able to report that to the user. We cannot do it right now). A version of Sat4j very close to 2.3 was used in the last MISC internal competition in p2cudf: http://www.mancoosi.org/misc-live/20110225/results/ We got there the best results we ever got with p2cudf. The bugs found by Sat4j users on that version: http://jira.ow2.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SAT+AND+issuetype+%3D+Bug+AND+affectedVersion+%3D+%222.3.0%22 do not affect the code we use in Eclipse. AFAIK Linux distros already use the latest Sat4j with Eclipse 3.6.2 (Fedora, Ubuntu dev version) and no big problem was discovered. http://www.spinics.net/lists/fedora-testing/msg99376.html eclipse-3.6.2-5.fc15 -------------------- * Wed Apr 27 2011 Chris Aniszczyk <zx@xxxxxxxxxx> 1:3.6.2-5 - New e-b snapshot - really fixes dropins issue. - update sat4j dependency to 2.3.0 I would say: very low risks.
Not sure this requires PMC +1, but I think it would be good to upgrade and the risk seems low. I suggest we get it in today and do a test build and have it ready for the next nightly.
I've released the patches to the director and platformOptions.txt files and updated the map file to point to an Orbit i-build that I declared (moved from the committers area to the public area). I'll run a test build.
The test build was successful. Closing.
