I don’t think “political” is quite the right term, but I do believe that the primary issues blocking more frequent or continuous releases are not technical in nature. After all, other OSS communities that are equally large to ours or even larger seem to manage more than three releases a year. There are well-known techniques for addressing different levels of risk desired by various members of the community, such as multiple streams, yet we are not even experimenting with these.
I think that part of the problem is that the responsibility for defining simrel is assigned to the Planning Council, so when an idea sprouts in the broader community, the discussion inevitably ends with “talk to your PC representative”. There, unless I am mistaken, the council operates on consensus as opposed to majority rule, so it’s easy for some corporate interests to torpedo any changes. A related issue is that unlike a project, where any party that contributes sufficiently can gain a full voice by getting elected as a committer, the council membership is closed and is not based on meritocracy. Perhaps the Planning Council should be disbanded and a simrel project created in its place (epp can be a sub-project).
- Konstantin
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Monday, November 03, 2014 10:18 PM
To: mike.milinkovich@xxxxxxxxxxx; Cross project issues
Subject: Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in "4.4" repository.
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 <mike.milinkovich@xxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
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: cross-project-issues-dev-bounces@xxxxxxxxxxx
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
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223 (mobile)
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
