Bugzilla – Full Text Bug Listing
| Summary: | How to avoid, support?, document and test "loose requirements" | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | Thomas Hallgren <thomas> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | denis.roy, john.arthorne, pascal |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
|
Description
David Williams
I'm going to assign this to Thomas, since he was heavily involved in the previous issue and discussion at the end of Helios ... if not the instigator :) But I'm not implying all actions are his to solve. I just didn't want too much spam sent out ... so add yourself to CC if you want to follow this bug. Advice welcome. (And, you can assign back to me, Thomas, if you don't plan to do anything in this area). I think this should really be viewed as an enhancement in p2. There is no authoring format today for someone to define loose requirements (including with a range). We have discussed in the past being able to specify both a precise version and a range on a feature inclusion, and make it an option at install time whether you install strictly using precise versions (notion of "line-up"), or a range. I can't find an existing bug with this discussion but maybe Pascal knows of one. (In reply to comment #2) > I think this should really be viewed as an enhancement in p2. There is no > authoring format today for someone to define loose requirements (including with > a range). ... I think it is fine to view the _support_ of loose requirements as a p2 enhancement, and if you find that bug number, it'd be great to reference here ... but ... a) I think buckminster has an "authoring format" ... at least of a sorts (the sorts that doesn't play well with these other requirements of reproducible builds and revert-ability, so should not be used) b) _this_ bugzilla is meant mostly as a way to document how to avoid accidentally introducing "loose" requirements (or, more precisely, to document how to avoid breaking revert-ability). For example, if a plugin "requires" a package import, then should they (someone, somewhere) make sure a feature requires/includes a suitable version of that plugin. Can some revert "break" such a plugin accidentally? Maybe not. Maybe the supposition in bug 324419#c6 was/is incorrect? c) also this issue is about how to test. In http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg04201.html Jeff mentions it'd be a nice sanity check to test repos, but I've no idea how to do that ... so hoping someone will attach a nice working patch :) Is there a way to "test for revert-ability"? Or maybe we don't need to after all? There's plenty of other things we should test ... I'm not saying this is urgent ... just didn't want it to get lost. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Too much bitrot on this one. |