Community
Participate
Working Groups
Scenario: 1) Add a bookmark to http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout% 7E/platform-update-home/optionalSite/ 2) Expand 'Products' and select 'Root 1.0.0'. 3) Install it as-is (with all optional features) 4) Restart. Install e-fix e334. Restart. 5) Verify that the configuration is correct and that XYZBogus 1.0.0 includes XYZ 1.0.0.e334 and shows up arrow. 6) Start Eclipse WITH A NEW (CLEAN) WORKSPACE. Check the configuration. XYZ 1.0.0 shows up as an orphaned root feature. Expectation: only one version of each feature should be configured by the reconciler. It should resolve all the included features using the best match and ensure that all other versions are not configured. This problem happens on both 2.0.2 and 2.1 code base. It blocks both branch updates and e-fix updates (essentially all updates where only branches of the feature tree have been upgraded).
Action Taken: The reconciler's algorithm has a bug. The algorithm first attemtps to calculate all feature-root(s) (features with no parent), then calculates the tree of enable features based on the enable parents and finally disables any other feature(s). The current implementation had a bug where the calculation of the best-match always returned the exact match for an included feature. I fixed the bug and it seems to solve the issue at least on the Warning side. I will still need to exhaustively test, see if we can disable efixes for disabled features and investigate the logic if there are more than 2 possible childrens for an included feature (the exact, the best-match and another one) Action Plane: Test
A reminder: as per our discussion, add a pass whereby all the e-fixes that reference disabled features need to be disabled as well. This has to be done carefully because these e-fixes will most likely include children (through best match) that are included in other branches, so we must only disable e-fix children not included in other features. Probably another orphan check will need to be done after this. Note that e-fixes can include e-fixes (although when they do, the match is 'perfect').
If this is fixed, it will solve the problem of not being able to ship efixes as unzipped in the file tree? Currently efixes must be downloaded. However since the reconcile doesn't happen in other workspaces this now shows up as a bug. I would assume that once this is fixed efixes could be shipped as part of a prodcut install and the reconciler would do the correct thing.
We are trying to address this with a somewhat bitter taste that we really shot ourselves in the foot when we put platform configuration in the workspace. For 2.2, we will revisit this whole area and see if we can divorce user data and install state, because it is causing a lot of problems. The cleanest possible way for a user to avoid these problems is to use '- configuration <URL-to-config-file>' attribute when launching eclipse. This will allow him to keep one configuration while having several workspaces. Failing that, we must reconcile, and reconcilation is more of an effort to 'reverse- engineer' platform configuration than a real solution. When we fix this defect, it will be the best effort to date to reconstruct missing configuration from file system state, but if the user disabled some features manually in the other workspace, we will naturally be missing that information. This is not completely unheard of - think of user accounts on Windows where desktop settings etc. are only per user. However, you do have an option to install a product for all the users, so in 2.2 we should explore this idea further (ask the user if he wants the state to be in the workspace only, or to apply to all the workspace). We may also introduce a notion of a 'configuration' as a UI metaphore (managed in the Preferences) and separate them from the workspaces.
Action Taken: implemented reconciliation for included features. Sent jar file to cisco@ca.ibm.com. Action Plan: implementing new feature: efix reconciliation
Action Taken: the new efix reconciliation strategy looks like this. We will first attempt to find all the patches that are enabled. we will not compute the included patches as the Update UI manages such case (where a super patch is enabled but an included efix is disable) We then make sure that all patched feature of the patch are currently disabled. Action Plan: test, test, test
Action taken: OptionalSite testcase: Install efix e452, installe root 1.0.0, install root 1.0.1, reconcile e388 is enable with warning
Action Taken: I alked to Steve about it and I think he found a solution: the new strategy for disabling features will look like this... 1) find top level features as before 2) find efixes top level features within the top level feature 3) expand other features (not the efixes top level) and find what should be enabled (best match rule) 4) find all efixes in all features 5) for each efix, check if efix should be disable (it should be disable if it patches a disabled feature) 6) if we need to disable an efix. a) check if the efix included feature belong to list of configured features from #3, if not disable the included feature.
Action taken: Quickly tested new algorithm and issue in comment #7 does not occur. I sent Jar file to Steve for quick test. Action Plan: continue testing
Action Taken: The optimistic reconciliation scenarios and tests are successfuls after applying this new feature. [all but one: bug 31940] During testing of other scenarios (partial update, partial reconcilition..) to ensure stability we (including product test team) found other bugs and decided to log them so we can make sure they are fixed in both 2.0.3 and 2.1. Other bug resulting from this one should be considered test bug for this new function and not regression tests. we are still pursuing the tests this week end to provide a stable 2.0.3. It will contain fix for bug 31730 and subsequent linked bugs resulting of testing.
Action Taken: found new scenario partial-reconciliation where new found efixes should not be enable as the feature they patch is now Disable in the workspace. Fixed warning. Action Plan: re-validate non-regression tonight and tomorrow morning (5am EST)
Action Taken: tested. Action Plan: Close as fixed in 2.0.3 and 2.1
*** Bug 42567 has been marked as a duplicate of this bug. ***
