Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] A new EPP SOA package

I understand that they are concerns regarding the quality of the  
package due to the tight schedule, but I am confident that we will be  
able to ensure the quality of the package. Providing a rather small  
package that is not that featue rich might be an advantage under these  
circumstances. The basic testplan is twofold
On the one side we will reuse our rather elaborated automated tests  
for the swordfish tooling which are based on swtbot and run them  
against the package.
As this will only prove  the basic functioning of the IDE and the  
Swordfish tooling we will also do manual tests. We have specified a  
detailed script for a webinar we plan to record that shows how to  
implement services with Swordfish. We are on the way to transform this  
script into a set of test cases that we will manually execute against  
the package. The test cases will touch all components of the package.  
(BTW I was trying to learn how other package are tested, but was not  
successful in finding the respective test plans:-)


Zsolt

Am 08.09.2009 um 17:25 schrieb Ian Skerrett:

> 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



Back to the top