Community
Participate
Working Groups
With the latest changes, we removed an operation to only return the bundles associated with a specific container rather than all bundles in the profile. We previously did this using an additional slicing operation.
Created attachment 182532 [details] screenshot showing the problems yup. I'll take a look at this and see about putting it back. It is interesting IMHO because otherwise you get bogus counts in the UI. May be trivial but I've always found the counts useful when managing targets.
I've added back the slicing and am still tweaking a bit. The next set of patches on Bug 321870 will include a fix for this problem.
I have been playing with various slicing approaches in selecting the bundles to attribute to the various containers but have not struck upon a combination that makes the tests pass out of the box. Using something like the original is as close to passing (as you wuld expect) but does not really give the "right thing" to the user IMHO. Using something more precise for the user makes more tests fail. It is a little unclear which test data "is the way is should be" vs which is "its the way it is/was". That is, what tests are testing the way the behaviour should/must be vs validating that the implementation is still producing the same thing. Some guidance would be appreciated.
We can change the tests to respect the new content if the content provided is more useful. We also need to check that the counts provided in the UI are reasonable and useful to the user.
OK. Then we need to talk about what numbers make sense in the UI. I have cases where the number of bundles attributed to the same container could be 187, 17 or 4 just by changing the way we handle this issue. :-)
Fixed with bug 331068
