Community
Participate
Working Groups
This enhancement is a follow-up, of sorts, from a Planning Council discussion (which itself was apparently a follow-up of RT PMC discussion :) But, after the meeting, it occurred to me something "missing" from Eclipse's update design are user-meaningful "flags" as there is in other (OS) Platform's and some software. Some software allows users to "fine tune" the type of updates that they are notified about, such as a) security fixes b) critical c) important Or similar. I'm sure there's some p2 magic where attributes of "updateType" could be added to an IU ... but, to be useful, we'd need some corresponding UI in the Platform to allow users to express that preference. (If not other metadata/repository changes). As it is, with Eclipse, some users (myself included) turn off any update checking, but then they might miss important security updates. So, ... just one small part of improving the whole update story? And security story?
The metadata has the ability to express this sort of information in the IUpdateDescriptor that is part of any IU. Right now we define two levels of severity but more can be defined. On the UI side, I'm not sure how this would manifest itself (maybe a decorator when we have the update). But the most interesting problem is here is where does the information about the severity come from? We know it is in the IU, but ppl install products or feature and so the question really becomes whether the update should look at all the IUs that are part of the update and check the severity or if instead the information should be doubled in the feature.
I think feature is the most appropriate place to code the information. At least, would have the highest priority to do ... would capture the majority of use-cases. I am mostly concerned about "between releases" patches, where there is something urgent that many people would need. And maybe I don't know what you mean by decorator, but that sounds like overkill. What I imagine is some check boxes near where users are currently asked their preference for "major" updates vs. minor or service updates. I suspect most users understand that to mean degree of change (and amount of risk :) but currently there's no way for us (committers) to denote things like "security fixes" (which are rare, but important) or "critical fixes" which might denote fixes for major memory, performance, or crash bugs. "Important fixes" I'd see as meaning as fixes for "major" bugs, which might be very important for some users that use some function, but which many people could skip. While I don't know much about p2 internals, I'd think have this information at the feature (or patch feature) level would provide some performance benefit? There might be fewer things to check to see if they were one of the "security" or "critical" fixes for example, if that's all the user had turned on?
See also bug 316702.
