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
- Reconsider patch/update policy for EPP Packages
or, better, if specific to this
case, to quote my original note:
(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,
Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx>
11/03/2014 07:03 PM
Equinox fix for Luna SR1 now available as a feature patch in "4.4"
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.
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev