I would like very much for the AC to be involved in establishing
priorities for development funding [1]. To that end, I'd like
to propose that we start work on a process for determining and
maintaining the priority list. What do we need to do to get started?
In a related note, it's time to revise the EDP. I created an
umbrella bug [2] some time ago and have hung a few blockers on it.
Your input is appreciated.
Also related, I believe, is an idea that I had for a hackathon
concept at EclipseCon [3]: I'd like to use EclipseCon as an
opportunity to get committers together and focus attention on issues
that will benefit from face-to-face work. The hackathon runs for the
duration of the conference; people come and go as needed (e.g. to
attend a talk).
Your thoughts and other input on these matters will be greatly
appreciated.
Thanks!
Wayne
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=471462
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=463857
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=471463
On 26/06/15 06:06 AM, Mike Milinkovich
wrote:
Leaders of the Eclipse community,
There are a number of topics that I would like to bring everyone
up to speed on. All of this is going to be announced over the next
month or so. So I would appreciate it if you don't blog, etc.
until the Foundation has the opportunity to communicate it to the
community and public.
A lot of this can be viewed as a re-balancing. The Eclipse
Foundation has in many ways focused more on the needs of our
technology adopters than both our users, and you, our committers.
I am not saying we're completely changing, but the time has come
for a bit of a re-calibration.
IP Process
We are going to be making some changes to reduce the burden of the
IP process on projects. There are lots of implementation details
that need to be worked out, but the Board approved some
significant items this week for the EMO to go implement. A few
examples include:
- Eliminate piggyback CQs, and rely on automation to report
where dependencies are being used.
- Automate CQ creation for contributions > 1KLOC
- Removing the requirement that committers who contribute >
1KLOC to another project need to file a CQ. (Sadly there is a
corner case for about 75 committers whose employer did not
allow them contribute to any projects other than the ones
listed in the employer consent form.)
- Completely eliminate IP reviews for service releases of
previously-approved dependencies, and significantly reduce the
review we do for minor revision releases. CQs will still need
to be filed, but the time-to-close will go way down.
Development Funding
The Eclipse Foundation is going to start funding some
development of our core platform and Java IDE, paid for by
corporate and individual donations. We will also be starting a
member-led working group to help co-ordinate and prioritize
corporate contributions. In mid-July we are going to be
announcing that all Friends of Eclipse contributions
will be used to fund development. We are going to be putting on
a donation push, with the hope that this message will result in
an increase of donations, which are currently running at about
$140K/yr. Earlier this year Ericsson kindly provided us with a
non-trivial amount of funds, and a list of priorities. That
single contribution had a material and positive impact on the
Mars release.
The Eclipse Foundation will be working with the Eclipse and WTP
PMCs to establish priorities for what we fund with the FoE
monies. On the other side of the equation, we are going to be
working on a transparent process for how the money gets spent,
and who the EF funds to do work. I trust that it will not be a
surprise that self-employed committers, and member companies
will all be considered as preferred sources.
This is a big change from the status quo. But it is not a
panacea. Unless our corporate contributions vastly exceed our
current expectations, we are not going to have the funds to make
dramatic changes to how things happen around here. But we've
already demonstrated in Mars that even a relatively small amount
of funds can have a pretty positive impact.
Simultaneous Release
I am not exactly sure how to go about getting closure on this, but
I would like to see Eclipse move to more of a "rolling release"
style. Users simply don't want to wait a year to get a new
feature. On the other hand, adopters want stable, maintainable
releases. There have been many discussions on this list and others
about increasing the frequency with which we ship. Let's figure
this out. Can the Eclipse Foundation help by hosting a meeting or
two?
Eclipse Development Process
Nothing tangible to report here, but please be aware that
Wayne is gearing up for his bi-annual review of the EDP, and we
will be looking for ideas on how to simplify what we ask our
projects to do.
I am personally very excited about these changes. There is a lot
going on, and all of it heading in a positive direction. I hope
you agree.
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
|
