[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Luna quiet week

Hi Wim,

I'm going to go ahead with a meeting at 9:30am pacific/6:30pm GMT today (Monday), as that's what we can do today with all schedules.  I'm currently planning on Markus and Sakith attending, and that's who I'll send the invitations to in about 10 minutes.

Wim:  I'm going to ask Sakith to get a hold of you directly to discuss with you the definition of some new/additional remote service interfaces...that Sakith may use to create PDE templates for (for his gsoc project).   He's in the Columbo/Sri Lanka time zone, so it should be easier for him to hook up with you time-wise than it is for he and I.

I will arrange a different day/time for next meeting.

Scott

On 6/16/2014 2:01 AM, Wim Jongman wrote:
Hi,

I cannot make it

9:30am pacific time
GMT ++02 Time (Local):

6:30 PM (18:30)

I can make it 20:00 GMT+2 which is 11:00am pacific.

Please note that when you want to reschedule or want to plan a new meeting in the next three weeks, it is best to fit it somewhere between soccer games.

Wim


On Thu, Jun 12, 2014 at 7:29 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Folks,

Luna M4 is being finalized as we speak...and the Luna quiet week is next week [1], which means it's now time to discuss ECF 3.9.0 :).

ECF 3.9.0 will require some coordination for reasons presented below, and so I would like to restart our bi-weekly conference calls.   I propose that we have as short-as-possible conference call every two weeks, and have it at this time:

Monday, 9:30 am pacific time, 6:30pm CEST

Further, I propose that we have the first meeting this coming Monday, June 16 and plan on using a Google hangout.

If this time and day doesn't work for you, and you wish to attend over the next couple of months, please propose a better day and time for you and we'll work something out.

Now...about the reason for conference calls.  There are several immediately pressing things for ECF:

1) ECF is currently under consideration/evaluation as the *reference implementation for OSGi R6 Remote Services/Remote Service Admin standards.  This is/would be very valuable for the project wrt visibility, publicity, and commercial adoption.   It would also be a great and well-deserved validation of all the hard work that has gone into ECF's RS/RSA impl over the past couple of years since RS/RSA spec has appeared.

What I mean exactly by 'under consideration' is that the OSGi Enterprise Experts Group (of which I and ECF committer Jan Rellermeyer are members) has received from me answers to the OSGi Alliance 'criteria for reference implementation selection'.  I submitted ECF's answers to the EEG prior to the Wed, May 28 meeting.   The response so far has been very good, as ECF has a *very* strong track record WRT legal criteria (licensing, provenance, etc) as well as technical criteria (continuous builds/integration, reliability, consistent releases over many years, modular and small impl, open and well-structured API/extensibility, etc).

2) In support of 1, I have completed all the necessary code changes for the R6-compliant impl of RS/RSA.  This work has been proceeding on a branch called 'rfc1.1' [2].   My expectation and desire is to merge all of this work into master *next week* (during Luna quiet week), and include it into ECF 3.9.0 in parallel with the release of the RS/RSA R6 specifications.  This should be very straightforward to actually do, since I've been regularly merging changes to master (in prep for Luna) into rfc1.1

3) Sakith Indula is working on Remote Services tooling for his Google Summer of Code project.   He is currently focusing on adding PDE templates for remote services (e.g. a time service template, other new remote service interfaces).   This is/will be only the beginning of ECF efforts in improved tooling for Remote Services creation, testing, debugging, deployment...i.e. the 'whole enchilada' for remote services development and usage.   e.g. remote services annotations, a 'remote service browser' (for testing/debugging/discovering), and better support for creation of remote services for small devices (i.e. Internet of Things).

For these three reasons...and many others that I'm either forgetting or choosing not to list here, I think we should have bi-weekly ECF meetings for the next few weeks.

Thanks...and hopefully see you on Monday, 16 at 9:30am pacific time.  Please let me know if you will attend, and the gmail address I should use for inviting you to the hangout.

Thanks,

Scott

[1] https://wiki.eclipse.org/Luna/Simultaneous_Release_Plan
[2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git?h=rfc1.1
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev



_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev