Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [rt-pmc] Re: Swordfish review slides

Title: Re: [rt-pmc] Re: Swordfish review slides
Ricco,
 
One item that jumped out at me in the slides was the bug summary. Given the complexity of a SOA runtime I was confused when I looked into the bug database. There is a single component (core) and no target milestones. That combined with the fact of your total 36 bugs 29 have been logged by Eclipse Foundation employees.
 
Are the project committers using the Eclipse bug database to track all open issues and enhancements or are they using a secondary system as well. It seems odd to me that you do not have more closed bug as you move towards a release and that you do not have any targets to track when a bug was closed for a given milestone/release.
 
Doug
-----Original Message-----
From: Ricco Deutscher [mailto:ricco.deutscher@xxxxxxxxx]
Sent: Tuesday, March 03, 2009 11:43 AM
To: Bjorn Freeman-Benson
Cc: Anne Jacko; Runtime Project PMC mailing list
Subject: Re: [rt-pmc] Re: Swordfish review slides

Bjorn,

thank you very much for your comments regarding the Swordfish release review docuware. The slides you’ve reviewed, however, were not meant to be final — Oliver sent them to EMO as a draft on Anne’s request, and we apologize if they haven’t been marked clearly as such.

Nevertheless, we understand your points and we will come back to you within the next 1-2 days.

Best regards,
Ricco


Am 03.03.09 01:16 schrieb "Bjorn Freeman-Benson" unter <bjorn.freeman-benson@xxxxxxxxxxx>:

RT PMC members,
The Swordfish project has sent in some slides for a 1.0 release review. In reviewing these slides, I note the following items which make me wonder how involved the PMC has been in preparing this project. Specifically, two issues:

  • The Larger Eclipse Community: the purpose of these reviews is to explain the project and it's status to the larger Eclipse community. The review is not just a checklist of hoops to jump through. For example:

    • Schedule: the purpose of listing the schedule is to demonstrate to the larger community the project's ability to set a schedule and to meet the schedule. Thus the schedule page in the docuware needs to list the actual planned milestones and planned dates and actual dates. Not just first and last milestones: all of them, with details.
    • Standards: the purpose of listing the standards is to explain to the community what standards the project is implementing and tracking. Thus the statement "strives to be standards compliant" is not good enough.
    • ...etc...

  • Maturity for a 1.0 Release: it's hard for me to see the project as ready for a 1.0 release given that:
    • All the API is provisional. That could be ok except that there's no plan for hardening the API and thus one wonders whether proper care has been put into the API design. The purpose of "provisional API" is not to allow projects to avoid spending the effort to create good APIs - rather, the purpose is to allow an "almost completed" API to be road tested with actual clients before be finalized.
    • The project only supports one messaging engine. It's hard to claim that something is a framework if it doesn't have at least two, preferably three uses/users.
  • I also note that the PMC has not yet approved this release. The PMC is supposed to approve releases before they are sent to the EMO.

I'm inclined to say "no" to this release review unless you all on the PMC can explain why I'm wrong here. Thanks.

- Bjorn

Back to the top