[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] RE: JSRs

Hi folks. I am going to take a look through the JCP documentation to make sure that we're allowed to discuss the vote in a public forum. Assuming that it's not a violation of the JCP rules, I will post notice of the votes as they come up to solicit discussion and recommendation from the Architecture Council members.

Ultimately, while input from the Architecture Council will be valuable in the decision making process, there are many factors that Mike and I consider when casting a vote on behalf of Eclipse.

More later.

Wayne

Oberhuber, Martin wrote:
Hi Boris,
thanks for bringing this up! Involving the AC is a great idea. And even if many of us won't have sufficient background to make an educated suggestion, it would be helpful as a first step if the AC got a list of specification organizations that Eclipse is involved in, and suggestions that are being voted on.
I do think that bringing this information to the AC may add considerable value for some AC members, thus increasing the value of membership, and thus increasing the value of strategic eclipse membership.
Cheers,
--
*Martin Oberhuber*, Senior Member of Technical Staff, *Wind River*
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm


    ------------------------------------------------------------------------
    *From:* eclipse.org-architecture-council-bounces@xxxxxxxxxxx
    [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] *On
    Behalf Of *Mike Milinkovich
    *Sent:* Mittwoch, 27. Mai 2009 19:28
    *To:* 'Boris Bokowski'; eclipse.org-architecture-council@xxxxxxxxxxx
    *Subject:* [eclipse.org-architecture-council] RE: JSRs

    Boris,



    I got a similar note from Bob Lee J



    After much discussion at the Board about getting involved in
    Specification Organizations
    <http://www.eclipse.org/org/documents/Eclipse_SpecOrgs_final.pdf>
    the agreed policy is that we (the EMO) will vote in the manner we
    (the EMO) think best helps Eclipse.



    It would be great to hear the opinion of others on how we should
    vote. Having the advice of the Architecture Council would be very
    helpful data point, I am sure. But in the end Wayne and I are
    going to make the final decision.



    Mike Milinkovich

    Office: +1.613.224.9461 x228

    Mobile: +1.613.220.3223

    mike.milinkovich@xxxxxxxxxxx <mailto:mike.milinkovich@xxxxxxxxxxx>



    *From:* Boris Bokowski [mailto:Boris_Bokowski@xxxxxxxxxx]
    *Sent:* May-27-09 12:56 PM
    *To:* mike.milinkovich@xxxxxxxxxxx;
    eclipse.org-architecture-council@xxxxxxxxxxx
    *Subject:* JSRs



    Mike, Architecture Council,

    The Eclipse Foundation is a member of the JCP SE/EE Executive
    Committee, which "is responsible for approving the passage of
    specifications through key points of the JCP"
    (http://jcp.org/en/participation/committee).

    Mike, you are the Eclipse Foundation's representative on that
    committee. On what basis do you make voting decisions? Would it
    make sense to involve the AC on this in some way?

    The concrete background of this is that I have been asked by Bob
    Lee, one of the proposed spec leads for JSR-330 "Dependency
    Injection for Java", that the Eclipse Foundation vote "yes" on
    this JSR which is up for "JSR review", i.e. whether it gets
    approval for development in the JCP. Personally, I think that the
    proposal looks good, and that it would be in Eclipse's interest to
    support the JSR, but it doesn't feel right that I just send an
    email to you without involving others from the Eclipse community.

    Questions? Comments?

    Boris

------------------------------------------------------------------------

_______________________________________________
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.