Re: [soa-iwg] ECF remote services

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Donald,

Donald Smith wrote:
> My worry about this thread is that there are two very distinct issues 
> that are getting conflated, and as long as that happens, I doubt there 
> will be any progress and just heated disagreement.
>
> 1 – The process of working groups, packages, charters and 
> distribution. I don’t think this group or this thread is the right 
> place for the conversation. It needs to take place with the board 
> Committer reps, at the Architecture council, at the EMO, etc. As I’ve 
> noted before, I don’t know if we’ll ever agree about how these work – 
> but the processes and programs have been agreed to and built in past 
> years after much consideration and debate. If there are things that 
> need to be addressed as you are saying – then the discussion needs to 
> happen elsewhere.

That's fine with me. But once again the charter has been invoked as 
justification for what is a poor decision...i.e. 'the charter says that 
X has to have both runtime and tools components therefore...'. So, as 
long as it's invoked to justify such a decision, it should be 
challenged....because such justification is wrong (and bollux to the 
argument that there was lots of consideration and debate...I just don't 
buy that that means it's reasonable).

> 2 – You are asking what looks like a very reasonable question to 
> include some well regarded software in the SOA IWG Package. I still 
> don’t think anyone has said no to that – just that the IWG requires 
> help with it’s integration and inclusion and it sure would be nice if 
> there was some way that it fit with the other components. The reason 
> is, because as you’ve noted there has been a lot of disjoint SOA 
> projects at Eclipse, and a very important goal of the IWG is to try to 
> decrease that. Just like the release trains have taken many years to 
> increase the cohesiveness of the core, the SOA IWG is looking to do 
> the same.

Then maybe it would be a good idea to not build a vertical/silo 
orientation into the charter (by essentially requiring that projects do 
everything themselves instead of working collaboratively)...and/or 
sanction the invocation of this rule to justify a decision about package 
inclusion.

We should remember that our/ECF's remote services work *does already* 
have tooling associated with it (as I've repeatedly made quite clear). 
So the whole argument about this is spurious (because even if a 
requirement to include tooling and runtime both were reasonable...which 
it is not...we have already met that requirement).

Scott