RE: [epp-dev] A new EPP SOA package

["Ian Skerrett" <ian.skerrett@xxxxxxxxxxx>]

I think it is important that we have the SOA package available for SR1.  A
couple of points:

- We can't get into a situation where the packages are tightly tied to the
release train schedule.  In the agile world we live in today, we need to
have the ability to respond to new requirements.  In this case a new group
would like to create a new package, so I believe it is important that we can
respond to their request.  

- As for quality, as with any package it is the responsibility of the
package maintainers to ensure the quality.  Like all the other packages,
Zsolt is responsible for testing and signing off on the quality. I agree it
would be nice to have more time to community feedback but I believe that is
Zsolt decision to make.

- In terms of the release review, of course if Swordfish does not pass then
they will not be able to release, so a package is moot.  However, it is very
easy to remove something.  :-)

- I agree it does seem that SOA package is close to the Java Enterprise
package but fortunately/unfortunately (depending on your perspective) the
intention of the packages is to appeal to a certain user profiles.  In this
case the user profile is a SOA developer not a Java developer.  The contents
are similar but we want to attract developers that are interested in SOA. 

In conclusion, I am a +1 on the SOA package.  For me it is important EPP
continues to be responsive and agile between release trains.  We can't live
in a static environment and only change once a year.

Ian


-----Original Message-----
From: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-bounces@xxxxxxxxxxx] On
Behalf Of David M Williams
Sent: Monday, September 07, 2009 9:24 PM
To: Eclipse Packaging Project
Subject: Re: [epp-dev] A new EPP SOA package

> Question: Is there anyone out there who is against (1)? Any objections 
from other package maintainers or team members?

I'm a little against '1'. I don't want my voice to make the decision, but 
I'll at least give a dissenting point of view and see if anyone else 
agrees (or disagrees). 

My largest concern is that there's no time for any use or feedback from 
the community or adopters. Part of the purpose of the simultaneous release 
(and packages, in my view) is not the end-result, but the build-up to that 
end-result. Seems like the plan for option '1' focus on only the 
end-result ... producing a package ... with out demonstrating the steady 
predictability of milestones and release candidates. 

A smaller concern is that I think 'Swordfish' is part of the package, and 
they are not having their Release Review until the very last minute (Sept 
14th or so?) 
So, there is some risk that it won't make it, and this won't be known 
until the very last minute. 

In fact, looking at the list of features, it seems like exactly the same 
thing as the EPP 'Java Package' (that is, the one that has mylin, and xml 
in it) except for the addition of 
- org.eclipse.wst.ws_ui.feature
- org.eclipse.swordfish.tooling.feature

So ... doesn't seem like anything that should be hard for users to install 
or construct. 

On the flip side, I see how the "working group" wants the publicity, etc., 
but I just don't like the packages being a "marking tool" without the 
normal path of users and adopters trying it out for a few months first. 
(Remember, normally, someone must be "in the build" for Simultaneous 
Release by M4 or M5, which translates into nearly 6 months of community 
use before release). 

Would "Galileo SR2" be an option? That'd at least give some time to 
publish some versions before it was officially released. 

But, like I said, mine is just one view and I don't feel so strongly about 
it that I'd be insulted if you or others didn't agree. I definitely don't 
want to be 'negative' to new things, I just felt it important to voice the 
counter point of view. I'm fine to go with your decision (as EPP lead) 
either way, without further discussion or justification. 

Good luck! 



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