[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [soa-iwg] ECF remote services
|
Scott,
Obviously you aren't willing to have a professional, courteous exchange
on this subject, so I will leave it at that.
For the reference of others reading this mailing list, here is the
process to create a package
http://wiki.eclipse.org/EPP/How_to_create_a_package. It is a bit out of
date, with references to Ganymede but the general principles are still
valid. Feel free to contact me if you have questions or need help.
Ian
On 1/13/2010 10:35 AM, Scott Lewis wrote:
Hi Ian,
Ian Skerrett wrote:
Scott,
You may not agree with the SOA IWG charter and think it is a bad
decision. That is your right and opinion but it doesn't make it wrong.
What makes it wrong is that it's wrong.
The reason we created the IWG concept is to allow organizations to
address the solution needs not being addressed by existing projects.
I agree 100% that asking Eclipse projects to do tools and runtimes is
not useful or consistent.
In other words: wrong.
However, I trust you agree developers do need tools and runtimes to
complete their job.
Yeah...that's why *as I've already said a number of times*...we *do*
provide tooling for the remote services work...by writing to
*standards* that are already supported via the tooling work of other
projects...PDE, DS, etc...along with some supplemental tooling of our
own (to deal with discovery...which is unique to remote OSGi services).
Therefore, the SOA IWG is trying to create an integrated solution of
tools and runtimes to meet the needs of a SOA developer. This is
exactly why we created the IWG concept.
Then why wasn't it created as an actual multi-project, multi-vendor
working group...instead of a single project, single-vendor 'working
group'? To actually meet those needs of the SOA developer in the only
way appropriate: to leverage all of the relevant projects.
I would also like to point out that packages can be created by any
committer, not just IWG. There is nothing stopping you from creating
your own package to meet the needs of your community.
This is bull**** Ian. Like all other projects we don't have the means
to do everything ourselves (i.e. just do our own package).
Besides...the process doesn't even allow doing one's own package
anyway (the EPP process for adding packages is still closed, as you
know).
Scott
Ian
On 1/12/2010 6:56 PM, Scott Lewis wrote:
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
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
