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
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
