[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse.org-architecture-council] Some news
|
I second that! That's the most exciting news I heard from Eclipse Foundation
in a long while. Would love to hear more about specific line items that were
funded through the foundation. Perhaps we can have a bugzilla tag for this
to make the list easily queriable?
Thanks,
- Konstantin
-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of
Michael Scharf
Sent: Friday, June 26, 2015 12:54 PM
To: mike.milinkovich@xxxxxxxxxxx; eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Some news
Hi Mike,
this is really exciting news! A huge +1 on all of them!
Michael
On 2015-06-26 12:06, 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.
>
> --
> Mike Milinkovich
> mike.milinkovich@xxxxxxxxxxx
> +1.613.220.3223 (mobile)
>
>
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-coun
> cil
>
> 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.
>
_______________________________________________
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.