Skip to main content

[jsr363-experts] Re: Feature Freeze before Final Draft

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: Feature Freeze before Final Draft
  • Date: Tue, 28 Jun 2016 13:14:16 +0200

Ok thanks. Guess if there's no mandatory requirement by PMO nobody needs an
address, do you?

Regards,
Werner


On Tue, Jun 28, 2016 at 3:57 AM, Leonardo Lima 
< >
 wrote:

> You can keep only V2COM, please :) the other phrases are slogans.
> Regards,
> Leo.
>
>
> On Monday, June 27, 2016, Werner Keil 
> < >
>  wrote:
>
>> It was on the V2COM site earlier, but now it says "- making *IoT* happen" 
>> so
>> whether or not the "Hardware + Software" was also more a slogan, I guess we
>> can drop it unless Leo says otherwise;-)
>>
>>
>> On Tue, Jun 28, 2016 at 12:29 AM, Jean-Marie Dautelle 
>> <
>> > wrote:
>>
>>> Copyright 2014-2016 Jean-Marie Dautelle, Werner Keil, V2COM
>>>
>>>
>>> On Tue, Jun 28, 2016 at 12:29 AM, Jean-Marie Dautelle <
>>>  >
>>>  wrote:
>>>
>>>> Hi Werner,
>>>> I am fine with your proposition, but since the official spec lead is
>>>> "V2COM", I would remove "- Hardware + Software" (confusing since this is 
>>>> a
>>>> software only specification).
>>>> Cheers,
>>>> Jean-Marie.
>>>>
>>>> On Mon, Jun 27, 2016 at 4:05 PM, Werner Keil 
>>>> < >
>>>> wrote:
>>>>
>>>>> Btw. in the Final Release at least of JCache it was gone:
>>>>>
>>>>> Specification Leads: Oracle America, Inc. and Greg Luck
>>>>> ("Specification Leads")
>>>>>
>>>>> Release: March 2014
>>>>>
>>>>> Copyright 2014 Oracle America, Inc. and Greg Luck
>>>>> All rights reserved.
>>>>>
>>>>> So everyone, especially V2COM/Leo please advise if you need the
>>>>> address or
>>>>>
>>>>> Specification Lead:  Jean-Marie Dautelle, Werner Keil, V2COM
>>>>>   ("Specification Leads")
>>>>>
>>>>> as the Spec states now was fine?
>>>>>
>>>>> The Copyright line
>>>>> Copyright 2014-2016 Jean-Marie Dautelle, Werner Keil, V2COM - Hardware
>>>>> + Software ("Jean-Marie Dautelle, Werner Keil, V2COM")
>>>>>
>>>>> refers to V2COM with the full title, please also check if that's
>>>>> correct and we should use the same in the "Spec Leads" attribute?
>>>>>
>>>>> JCache had a totally weird numbering scheme btw, its PFD was JCache
>>>>> 2.9 followed by JCache 1.0 for the final release ;-P
>>>>>
>>>>> I assume 0.9 for the PFD is therefore fine followed by 1.0 in our
>>>>> case?;-)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>> On Mon, Jun 27, 2016 at 3:59 PM, Werner Keil 
>>>>> < >
>>>>> wrote:
>>>>>
>>>>>> Jean-Marie, Leo/all,
>>>>>>
>>>>>> Could you please have a look at the (Evaluation) License in the Spec
>>>>>> Document and advise, if either of you require the corporate address in 
>>>>>> the
>>>>>> license as per:
>>>>>>
>>>>>> 7. The version number of the specific specification document you are
>>>>>> submitting, the anticipated release date, and the full corporate name 
>>>>>> and
>>>>>> address of the Spec Lead Member. This will be used to generate the
>>>>>> evaluation license for the posting. If you wish to include this in your
>>>>>> download bundle(s), please send this information to 
>>>>>> 
>>>>>>  at
>>>>>> least 2 days before submitting the rest of the materials.
>>>>>>
>>>>>> JSRs 107
>>>>>>
>>>>>> http://download.oracle.com/otndocs/jcp/jcache-2_9-pfd-spec/license.html
>>>>>> or 354
>>>>>>
>>>>>> http://download.oracle.com/otndocs/jcp/money_currency-1_0_RC3-pfd-spec/license.html
>>>>>>
>>>>>> show, at least one of the Spec Leads' address was mentioned. In case
>>>>>> of 107 it was only that of Oracle, so unless the license could be
>>>>>> completely without address, we may follow what e.g. 107 did and use the
>>>>>> address of the corporate Co Spec Lead V2COM.
>>>>>>
>>>>>> Leo, would that be OK from your point?
>>>>>>
>>>>>> Thanks,
>>>>>> Werner
>>>>>>
>>>>>> On Wed, Jun 22, 2016 at 10:39 PM, Werner Keil 
>>>>>> < >
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Jean-Marie,
>>>>>>>
>>>>>>> Thanks a lot for the input. Will do in the coming days (Unit already
>>>>>>> in progress)
>>>>>>> Any suggestion about the number of weeks between a PFD and a Final
>>>>>>> Ballot or anticipated date for Final submission,see
>>>>>>> https://jcp.org/en/resources/guide-pfd
>>>>>>>
>>>>>>> And see item 7, it seems PMO at least needs to verify address or
>>>>>>> other information they had before.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Werner
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 22, 2016 at 9:33 PM, Jean-Marie Dautelle <
>>>>>>>  >
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>> For getProductUnits/getProductDimensions, my preference goes to
>>>>>>>> getBaseUnits/getBaseDimensions (more natural to me)
>>>>>>>> Cheers,
>>>>>>>> Jean-Marie
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 21, 2016 at 6:25 PM, Werner Keil 
>>>>>>>> <
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Not sure, if that's a good idea?
>>>>>>>>>
>>>>>>>>> Keep in mind, with the whole election and a huge number of EE JSRs
>>>>>>>>> all facing Renewal Ballot immediately after JavaOne I don't think 
>>>>>>>>> we get a
>>>>>>>>> ballot done before the very last moment (since Public Review 
>>>>>>>>> started in
>>>>>>>>> January the latest a Final ballot should start was also the end of 
>>>>>>>>> the
>>>>>>>>> year) with 10 or more EE JSRs facing Renewal Ballot automatically 
>>>>>>>>> plus
>>>>>>>>> there could be new EC members (ratified like V2COM, SouJava or 
>>>>>>>>> others quite
>>>>>>>>> rarely, only if a member should no longer wish to participate) to 
>>>>>>>>> vote on
>>>>>>>>> it then.
>>>>>>>>>
>>>>>>>>> I'm not afraid either way, even if others than myself should be
>>>>>>>>> elected (given the ability to participate I have a solid track 
>>>>>>>>> record, so
>>>>>>>>> likely run again unless something "very bad" happened with the 
>>>>>>>>> whole Java
>>>>>>>>> EE situation and the role of the EC;-) but it would be a hassle to 
>>>>>>>>> go into
>>>>>>>>> ballot then, especially if the Java EE situation could escalate and 
>>>>>>>>> EC
>>>>>>>>> members may be drawn into a "negative spirit" like in 2007.
>>>>>>>>> Jean-Marie who hosted that "famous barn F2F" probably knows that
>>>>>>>>> best, others in the EC like Geir also should, so would we rather 
>>>>>>>>> try to
>>>>>>>>> reach Final before that, around the July/August timeframe, and leave
>>>>>>>>> Hackathon etc. for a possible MR or 2.0 or should we risk getting 
>>>>>>>>> sucked
>>>>>>>>> into that sort of "politics" again as 275 partly did? (the Public 
>>>>>>>>> Review
>>>>>>>>> ballot was literally a month after the Oracle takeover:
>>>>>>>>> https://en.wikipedia.org/wiki/Sun_acquisition_by_Oracle)
>>>>>>>>>
>>>>>>>>> Happy to hear a quick response by others, Jean-Marie and if they
>>>>>>>>> can Martin on behalf of major downstream projects like GeoAPI.
>>>>>>>>>
>>>>>>>>> Keep in mind, Patrick stated, using JSR 275 is "half-legal"
>>>>>>>>> especially for commercial products, so we should also offer them a 
>>>>>>>>> safe
>>>>>>>>> alternative as soon as possible.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Werner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 21, 2016 at 6:03 PM, Leonardo Lima <
>>>>>>>>>  >
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> Werner,
>>>>>>>>>>
>>>>>>>>>> I think it should be best to have the JSR as "almost-final" (I
>>>>>>>>>> believe that'd be proposed final draft?) by JavaOne. That way, we 
>>>>>>>>>> can still
>>>>>>>>>> gather input in hackergartens and/or BoFs. We can have everything 
>>>>>>>>>> ready to
>>>>>>>>>> file for Final just after 1-2 weeks after J1.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Leo.
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 21, 2016 at 7:48 AM, Werner Keil <
>>>>>>>>>>  >
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Please also review the Spec Document again if you can.
>>>>>>>>>>> The license paragraph exists for "Evaluation" and
>>>>>>>>>>> "Implementation". Only when the Final version is approved and 
>>>>>>>>>>> released both
>>>>>>>>>>> will go out to separate download deliverables (see all major new 
>>>>>>>>>>> JSRs that
>>>>>>>>>>> went final like Money
>>>>>>>>>>> https://jcp.org/aboutJava/communityprocess/final/jsr354/index.html,
>>>>>>>>>>> JCache, etc.)
>>>>>>>>>>>
>>>>>>>>>>> For the Proposed Final Draft only the "Evaluation" part is
>>>>>>>>>>> relevant.
>>>>>>>>>>> Aside from brushing up to SPI changes, I added another Use Case
>>>>>>>>>>> chapter on DevOps and Cloud. Quite a hot topic and thanks to 
>>>>>>>>>>> being picked
>>>>>>>>>>> up by PCP/Parfait with the latest releases it is of course a good 
>>>>>>>>>>> thing to
>>>>>>>>>>> mention (aside from everyone staring at or rushing to the Cloud 
>>>>>>>>>>> right now;-)
>>>>>>>>>>>
>>>>>>>>>>> We aim for Code-freeze of the API and RI pretty much around June
>>>>>>>>>>> 30/July 1 (if there was any issue or significant input for 
>>>>>>>>>>> changes we still
>>>>>>>>>>> have the weekend)
>>>>>>>>>>> July 4 is a holiday in the US, so PMO would not process anything
>>>>>>>>>>> before the 5th, so around then looks good to submit it. Depending 
>>>>>>>>>>> on how
>>>>>>>>>>> fast it's put online, the community and EC members may see it 
>>>>>>>>>>> before the EC
>>>>>>>>>>> call on July 12th, but the Proposed Final Draft is just for 
>>>>>>>>>>> review, no
>>>>>>>>>>> ballot there yet. JSR 354 had its PFD on March 13 and Approval 
>>>>>>>>>>> Ballot on
>>>>>>>>>>> April 28. Final was out exactly 2 months later on May 13. Even if 
>>>>>>>>>>> JavaOne
>>>>>>>>>>> was to snub and ignore it again (unlike the Awards) or Oracle 
>>>>>>>>>>> ended up with
>>>>>>>>>>> a "JDK Personality Show" while the community looks for other 
>>>>>>>>>>> forums like
>>>>>>>>>>> DevoXX, etc. a Final date ideally before JavaOne looks best and 
>>>>>>>>>>> looking at
>>>>>>>>>>> 354 doable.
>>>>>>>>>>> There's a Creation Review for Java SE 9 Umbrella (actually right
>>>>>>>>>>> now) and JSON-B has a Public Review Ballot at the end of July. So 
>>>>>>>>>>> it could
>>>>>>>>>>> be best to aim at a nearby date, otherwise there are not too many 
>>>>>>>>>>> ballots
>>>>>>>>>>> anyway.
>>>>>>>>>>> JSR 330 (Dependency Injection) showed, there seems almost no
>>>>>>>>>>> rule for a minimum PFD duration. It went out on Sep 22 followed 
>>>>>>>>>>> by the
>>>>>>>>>>> ballot starting only a week later on Sep 29. I'd say at least 14 
>>>>>>>>>>> days could
>>>>>>>>>>> be good in our case if asked, if you think we should take longer, 
>>>>>>>>>>> please
>>>>>>>>>>> advise.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Werner
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> It is not the strongest of the species that survives, nor the most
>>>>>>>> intelligent. It is the one that is most adaptable to change. - 
>>>>>>>> Darwin's
>>>>>>>> Origin of Species (digest)
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> It is not the strongest of the species that survives, nor the most
>>>> intelligent. It is the one that is most adaptable to change. - Darwin's
>>>> Origin of Species (digest)
>>>>
>>>
>>>
>>>
>>> --
>>> It is not the strongest of the species that survives, nor the most
>>> intelligent. It is the one that is most adaptable to change. - Darwin's
>>> Origin of Species (digest)
>>>
>>
>>
>
> --
> Enviado do Gmail para celular
>


[jsr363-experts] Re: Feature Freeze before Final Draft

(continued)

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/22/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/22/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Jean-Marie Dautelle 06/22/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/22/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/27/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/27/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Jean-Marie Dautelle 06/27/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Jean-Marie Dautelle 06/27/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/27/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Leonardo Lima 06/28/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/28/2016

[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 06/30/2016
 
 
Close
loading
Please Confirm
Close