August_7_2013.md
October 9, 2023 ยท View on GitHub
Logistics
Meeting Title: |
Planning Council Conference Call |
Date & Time: |
Wednesday, August 07, 2013, at 1200 Noon Eastern |
Dial in: |
(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.) Phone Numbers: (Check Asterisk/Numbers for more or current phone numbers.)
|
Members and Attendees
width="100%" valign="top" |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
width="100%" valign="top" |
|
Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while, 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 D = delegated X = not expected
Announcements
- New Member: Dani Megert is now the Eclipse PMC representative to the Planning Council. Thanks to John for years of service. Thanks Dani for volunteering to take his place.
Luna Planning
- Is there confusion/contradictions about "unreleased components in Sim. Rel. repo"? See .
-
For reference, see current policy.
*It was thought this one deviation was a "fluke" and no systematic action needed; that for the most part, everyone understands* - ''a) can't release code under another project's namespace (can "include" it, if previously released) *b) if unreleased code is desired to use (it is, after all, EPL) you must "refactor" it into your own namespace, following the usual rules of attribution, maintaining copyright info, etc.*
- Are we "too lax" in versioning requirements? Especially for "maintenance"? See cross-project list posting. [To be honest, I do not recall what specific situation this is about?]
-
*Ed explained the situation to us (involved versioning issues
between XText and UML2) and it too sounded like a rare case that
did not need to be "policed". But does highlight the importance
of correct semantic versioning and not "adding features" with a
mere "service increment".*
- I have started scheduling Luna milestones. I think first 4 or 5 will be similar to previous years.
-
* Appears that timing of EclipseCon in 2014 may effect how M6 is scheduled. It comes "the last week" of what would normally be M6, instead of M6 finishing first. * See Luna/Simultaneous_Release_Plan.
*Most favored completing M6 before EclipseCon, even though that is the "API Freeze milestone". DW to workout that schedule in time for reps to review with their projects before September meeting (and alternatives, if any seem to exist).*
- Can/should Planning Council say projects "should" contribute source to common repo? Or continue to "leave it up to projects" to decide?
-
See thread around
<http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09506.html>
Possibly
\[Remember, we should make this decision based on principle, not
the one request for an "Ultimate Package" (), since a) we should
always work on principles\!, and b) this package may or may not
come to fruition.\]
-
*It was generally agreed we should continue status quo of
"leaving it up to project" ... let their adopters and
community drive any changes needed/desired. Primarily,
simply not to "add process or rules" to what many think is
already too many rules and processes and additionally, it
was commented, it is hard to "draw the line" ... what about
"types of documentation", or "examples" ... i.e. there is no
one answer that fits all projects.*
- Discuss more frequent "(un?) coordinated releases" or updates to common repo or updates to EPP packages. (Doug, Ian).
- See Ian's summary at http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02168.html. For some fun reading, I looked up the original bug on how we got to the names of "SR1/SR2" .. For reference, see current policy.
-
*This item had a long discussion, covering many area, and for
the most part, the status quo will be maintained for now.*
-
*A couple of things seemed to be agreed upon:*
-
*1) This is not something to change "this year" ...
something longer term ... but, we need to continue the
discussion and sort out the issues and solve them in some
manner -- that is, there was no disagreement that the
current schedule/rhythm does not satisfy all adopters and
projects and we need to see if we can improve on that.*
''2) Other groups/projects are leaning towards "continuous
delivery", why not us? (Or, do we already? :)"
*3) The _main_ issue (in terms of "deliverables") -- I
came to understand -- are the "EPP packages". That is, there
is nothing preventing projects from releasing any time they
would like to ... but the desire is that they'd like EPP
packages updated at the same time. Otherwise, only
"in-the-know" product adopters and a few savvy users know
how to go to a project-specific repo to get updates (or,
"new installs"). And ... some on planning council see that
as a bad thing (ha ha ... mostly my humor :) ... but ...
there are two sides to that story).*
*4) There appeared to be agreement that something like
"monthly releases" was not feasible ... too many places for
it to "go wrong" or cause lots of additional work for
projects (or, suffer from reduced quality). \[This was not
literally discussed at meeting, but to add an editorial
remark ... It seems hard enough to come out with 6 week
milestones. It is unclear if anyone actually needed
something as frequent as monthly or 6 week releases ... or
if it was more a "marketing" thing? If so, could there be
more/better/easier ways to "hype" milestones to get
equivalent interest? If the desire really is so
projects/adopters could release "whenever they were ready",
then I'll just point out there is a lot of hidden
assumptions being made in that case that in reality would
cause the same headaches the "release train" is meant to
solve -- primarily, it might appear to work fine the first
time through, if everyone goes in order, but then suddenly a
recent release, say of a commercial product, can not update
a few months later to get the latest of some pre-req, due to
some new feature/non-API use/deprecated API removal, subtle
change in behavior, etc, and then they end up having to wait
4 to 12 months anyway to get the fixes needed so they can
"get on" that, now old, version of the pre-req ... and
perhaps by then that pre-req no longer works with some other
pre-req that has since released. So, point is, anyone who
really desires this needs to think through the hidden (long
term) assumptions and "solve" them.\] But, in general, "a
mass repository" that may or may not work together did not
seem to get much excitement from Planning Council, if I was
hearing correctly.*
-
''A couple of items seemed to have very different points of
view: ''
-
*1) Is it a good thing to encourage "frequent feature/API
updates" or a bad thing? Examples were given on both sides.
On the one hand, it can be "hard on" adopters to react, if
there are large changes requiring adopters to do a lot of
re-testing/translating/marketing, etc. But, everyone sees
the advantages of it, especially for a "young" project like
EGit where they needed lots of quick improvements to be
complete, and useful.*
*2) An interesting, contrasting, case was made about "core
components" vs. "leaf components". To some, it seems clear
that something like the core platform should only apply
maintenance for SR1 and SR2 (to ensure only steady
improvements in quality) but on the other hand, there are
times that changes in the core platform is exactly what
other projects want, such as CDT, ... such as having a new
set of APIs added that allows them to come out with a better
(from their point of view) off-cycle release even though
"new API" can have unpredictable effects on other adopters.
Hard problem to solve. \[Just thinking aloud, perhaps some
special versioning conventions and tight p2 constraints
could allow relatively safe "forks" of something like core
platform APIs, without impacting adopters that were not
interested? In essence, CDT would release their own forked
version of the platform ... just thinking out loud ... not a
serious proposal.\]*
*3) Not to mention, sometimes even the core Platform may
want to add a new feature "off-cycle", such as if a new
version of Java comes out "mid-year", perhaps they'd want to
add "preliminary support" for it in SR2? Perhaps those types
of cases provides some hint of how to codify the practice of
adding features in a "service release" ... when ever
possible, they should be done as "optional", additional
features that adopters can take or leave. Not sure how to do
that with core API changes, though ... short lived fragments
that adopters can take or leave?*
-
So, lots to (continue to) discuss. Perhaps fundamentally, what
does "continuous delivery" mean for something consisting of
60-70 projects?
-
*Dani did state that the Eclipse PMC discussed explicitly, and
they want to keep the status quo. Even the names "Service
Release". That while new features can be allowed in SR1 and SR2
(as per our existing policy) that it is not something to
"encourage", in their view, ... they should be the exception
rather than the rule ... and the focus on SRs should be on
improving quality, not adding new features. (hard to do both,
with fixed resources ... or, more accurately, without vastly
increased resources :). New features should be "exposed" to
public in a number of milestones, before released. \[To
editorialize again, perhaps we need to do a better job of
encouraging use of milestones? I think some believe that a
"release" is the only thing consumers/users will use enough to
provide adequate feedback on a new feature.\]*
-
*Doug did state explicitly that his "focus on IDE" efforts (and
probable working group) were a whole separate issue and not in
the Planning Council realm. (whew)*
-
''\[post-call\] Another comment I heard, on arch. council call,
was that some adopters have been surprised to hear that "we"
allow new features in SR releases at all -- while I think "we"
want that to continue to be allowed, we should probably do a
better job of documenting them, perhaps as a quasi-"exception
process" so that it is more obvious to the community of "sim.
rel. consumers" when it does happen ... and document better some
of the basic information: what they change or add, if they are
optional, etc.
- Doug also wants to discuss him taking over the "releng role" and do aggregation builds using Maven/Tycho.
-
The focus is still on projects providing OSGi bundles in p2
repos, right? No matter what technology they used to get there?
What type of "project input" is required?
What type of "testing" is done that all is well formed and can
be installed together and is repeatable?
In particular, how are "IDE" vs "runtime only" components
treated separately?
What are concrete advantages?
-
*Doug said he would try to work on some prototypes. But (if I
heard him over the spotting phone connection correctly) this
wouldn't be anything to prevent planning to use the b3
aggregator approach as we have been and continue with that until
we know something more concrete, and then would be the time to
re-discuss). The approach (again, if I heard right) basically
makes use of a series of Jenkins (or Hudson) jobs, one
successful job triggering the next, and progressively "building
up" the repository. (I think is how he briefly described it).
\[Doug, please correct if I mis-heard any of this ... we didn't
spend much time on it.\]*
Progress on Action Items
- Editing of "Requirements Document"? (Dani and Neil)
- GSoC project for "Development Channel"? (Wayne)
- Improved "aggregator examples/doc". (dw -- no progress).
- But, about to send out "aggregator builds and streams ready" message ... depending on outcome of other items.
- [Orbit plan "by end of August". (dw -- no progress -- will likely be late, still "in September")]
- There were no "in-meeting" updates to any of these items, except Dani said they should start the editing during M2.
Kepler Retrospective
- Propose to start in August (if any extra time), finish in September.
- ''No time for a retrospective, per se, we'll try again in September ... please discuss with your projects or members you represent to see if there is anything we should document about "what worked" and "what didn't work". ''
Next Meeting
- September 4, 2013 - Regular First Wednesday Meeting
Reference
- EclipseCon face-to-face follow-through action items. For original meeting notes, see March_24_2013 and for discussion leading to action items, see April_10_2013. For last status update, see May_8_2013.