Difference between revisions of "Planning Council/September 07 2011"

Revision as of 16:36, 7 September 2011

Logistics

Members and Attendees

Note: "Inactive" refers to Strategic Members we have not heard from in a year or so, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.

Note: feel free to correct any errors/omissions in above attendance record.
Y = Yes, attended
N = No, did not
R = regrets sent ahead of time
X = not expected

Announcements

•  ?

Indigo SR1

What to do about breaking changes?

Achim: We discovered an issue where a change in Equinox broke EclipseLink for Jubula Bugzilla. We filed this bug which is a showstopper for us shortly after RC1 and the fix will be in RC4. This leaves us with very little time to do any testing on the release (Of course we've tested this on internal builds but the RCs where not testable). What is the recommended way to deal with this? We could have fixed this for the EPP packages by using specific versions of Equinox and/or EclipseLink but that would still leave the feature in the repo unusable.

davidw: I think you handled it in the best way possible. First, opening the bug, and second, drawing attention to it via your post to cross-project list. If you are asking if there is a way to extend the schedule for extra time for testing, I'd say "no", we seldom have (never, so far), and this case doesn't seem to need it. If you are asking if there is an "escalation path", I'd also say "no" (there is, if you feel you were being treated unfairly according to Eclipse by-laws, but "technical issues" would seldom qualify). In other words, "support" needs to be worked out between projects, and there is no absolute, perfect, guarantee of support. In general, there is certainly every intent to avoid breaking others, and from reading the bug report, it sounds like there were two known paths forward (fix the EclipseLink code, or the Equinox fix could have been backed out until later). If you want to scold the Equinox team for making a breaking change in behaviour ... consider is done! :) I do sympathize with them for this case though, as it is a difficult case to deal with ... where the API behaviour is implemented wrong, according to its documented contract, so in fixing that bug, it is discovered someone was accidentally depending on the incorrect behaviour. We must be able to "fix API behaviour" but, granted, it is risky to do so in a maintenance release and this case serves as an excellent reminder to all teams to use great care in doing that. All in all, this issue actually has an excellent outcome, thanks to you and your teams testing early, and thanks to Tom Watson and Tom Ware getting the fix in time for SR1. In other, cases, if had been found too late, shortly after the Service Release, it would have been impossible to "back out" the change, and would have only left out the option of someone producing a patch to apply after the fact. So, thank you for finding and thank you for drawing our attention to it.

achim: Just to make this clear: we don't blame any project at all. It was okay for the Equinox team to fix a problem in their API and the EclipseLink team responded equally well. Since the fix will be in RC3 we don't have a problem in testing the release, so all changed for the good. Our heart rate is back close to normal:-) I still don't know what would have happened if the issue had not been resolved. Is it possible to "skip" a service release in this case? Delivering a non-working feature/package obviously can't be a valid solution.

Tweak future SR drop windows?

Should we tweak schedule for SR2 (and future maintenance releases)? So weekly rhythm is same for maintenance as release? Namely, instead of Monday (+0) to Friday, have Friday (+0) to Friday?

Is there an issue with pack.gz files?

I've not understood the the implications of the cross-project thread on this topic ... does anyone else? Is there something to fix or solve?

I opened bug 356931. Does seem an issue, but does not seem to be a regression.

Any other issues?

Indigo Retrospective

Primary purpose is to brainstorm; to capture good and bad aspects of Indigo Simultaneous Release. While we want items to be actionable, we do not want to "judge" or get distracted by finding solutions, in this initial meeting.

We'll capture notes in Planning Council/Indigo_retrospective.

Before the meeting, please review last year's notes.

Juno Requirements

Support for Eclipse 3.8 workbench

We will have 4.2 as primary (hence the one used for EPP Packages) but ask participating projects to have a clear plan item titled, exactly, "Support for Eclipse 3.8 workbench" where possible descriptions might be similar to:

• Not at all. No support for 3.8 based apps.

• We will accept bugs against 3.8 based apps, but do not test or compile against it.

• We will compile against and somewhat test 3.8, though 4.2 is primary.

• We will support 3.8 as well as 4.2, but the exact functionality may differ.

• We will support 3.8 and 4.2 equally.

Next Meeting

• October 5, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).

Reference

Indigo Requirements

Juno Wiki page

Planning Council/Helios retrospective

Indigo Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO