Not sure what "political" means in this case -- just an eye-catching phrase? -- but there are a few reasons things are done as they are ... that have been explained so many times before ... that once more wouldn't hurt -- at least since Mike asked. :)
Resources and Risks: This is a "patch" (i.e. automatically some amount of risk). And, not everyone needs the patch. But to make it automatically apply to everyone's install makes everyone receive the risk. To do such a thing requires more work "up-front" to prepare patches of all "root features" that would be involved. And, to do it safely, would require a more testing (from all projects) to make sure no accidental negative side effects. And, in addition, would require more testing from all interested adopters to make sure no accidental side effects for them. In cases like that, we usually recommend to give "a months notice". So ... by then ... we'd be almost ready to "wind down" for SR2! (slight exaggeration, but the point is, it seemed that the cases where this was "blocking" others, they'd prefer to have it sooner, rather than later). Plus, I got the impression, a fair number of projects who needed it were adopters creating "products" for their users, so they can include it, if they'd like, in their "eclipse product". If not obvious to the causal reader, this was a fix in a low level package, "org.eclipse.osgi", where risk aversion skews the cost/benefit ratio curve. Limits of Feature Patches: This one isn't that applicable, I do not normally mention it in this context, but do now only due to Thomas' remark that he'd "like to see p2 leveraged (the way it was designed to) ...". The issue is, the only thing p2 was designed to do was to apply feature patches. There are many products/projects that do not use features, hence, they can not apply a "feature patch". They must come out with a "new release" or direct users how to install the fix by using p2 Director. I mention this since all that extra "up front" work, does not help those projects/products. And, besides that, there are a number of serious issues with feature patches, from what I can tell, which increases "risk" of using wide spread feature patches. Feel free to correct me, Thomas, if you, or another p2 committer, has fixed this limitation, since the last time it was discussed, 3 or 4 years ago? Or, if the bug list, is not valid? Or if I have misunderstood your remark? If you simply meant "had the ability to do continuous releases" I guess I do not normally see that as a p2 feature, but would mean this paragraph isn't relevant at all. (In at case, see previous paragraph for "continuous release" issues :). I was quiet at first, and will (try to) remain quiet after this note -- which, doesn't mean I don't care, I just don't have time or patience to have a long discussion on a mailing list of subtle nuances of pros and cons -- I am definitely aware there are pros in addition to the cons I've mentioned! --which have already been discussed many times, by many people, with no consensus, and the proper place to discuss it is in the various bugzillas, such as the one I opened in 2011: Bug 345503 - Reconsider patch/update policy for EPP Packages or, better, if specific to this case, to quote my original note: https://bugs.eclipse.org/bugs/show_bug.cgi?id=445122#c51 If there are any questions or issues, please ask/report in the bug. (and, I think there are others for the general case) and, the reason I think bugzilla is the proper place is that things explained in mailing lists tend to be forgotten, whereas in bugzilla, people can easily re-read the comments, to refresh their memory :). Or, if you want to change the predictable "3 times a year" Simultaneous Release cycle, talk to your Planning Council representative. (Though, as you can imagine, we have discussed it quite a bit, already). A few EPP projects might have designed things so they can get updates for their specific leaf components, but for something core like "org.eclipse.osgi" I believe care is needed to handle in a way that does not tax all committers limited time, and does not increase risk for users who do not need the fix. If it matters, I did discuss with an Eclipse PMC member, and I think it is their call if they should do a feature patch or a new, off-cycle release ... and believe I've captured the reasons why they would not want to do an off-cycle release. I hope that clarifies things a little ... at least, from my point of view, given my understanding. As an aside: This issue does serve as a a good reminder of the second part of my favorite mantra: test early, test often! :) ... since this bug this was introduced in RC2 (to fix another regression), if I recall. Thanks for reading, From: Mike Milinkovich <[email protected]> To: [email protected], Date: 11/03/2014 07:03 PM Subject: Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in "4.4" repository. Sent by: [email protected] On 02/11/2014 5:07 AM, Max Rydahl Andersen wrote: > ...or is there also some political agenda on how we provide these > updates ? For what's I worth, I am not aware of any political agenda that prevents us from providing these updates. If someone knows of such, please let me know either here on this list or privately. -- Mike Milinkovich [email protected] +1.613.220.3223 (mobile) _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
