[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Tim,
As you know, I am already involved in the server tooling with the
generic server tooling plugin as an implementor of the API. So I can
assist you with the implementation of the Tomcat plugins. And this way
I would not loose my edge as the first implementor of the API.
Gorkem Ercan
On Thu, 10 Feb 2005 10:03:14 -0500, Timothy Deboer <deboer@xxxxxxxxxx> wrote:
>
> Hi Arthur,
>
> I've been working steadily on cleaning up API and have received some great
> help and advice from Jim. However, between the server tools framework,
> Tomcat tools, the TCP/IP monitor, and the Web browser, I am stretched very
> thin. This isn't an alarm yet, but we should discuss and create a plan for
> getting this done within the given schedule. If anyone from the community is
> interested in getting involved, I would appreciate help in any of these
> areas.
>
> Thanks,
> Tim deBoer
> WebSphere Tools - IBM Canada Ltd.
> (905) 413-3503 (tieline 969)
> deboer@xxxxxxxxxx
>
>
>
> Arthur Ryman/Toronto/IBM@IBMCA
> Sent by: wtp-dev-admin@xxxxxxxxxxx
>
> 02/09/2005 06:04 PM
>
> Please respond to
> wtp-dev
>
>
> To wtp-dev@xxxxxxxxxxx
>
> cc Jim des Rivieres/Ottawa/IBM@IBMCA, John Wiegand <John_Wiegand@xxxxxxxxxx>
>
> Subject [wtp-dev] API Plan
>
>
>
>
>
>
> In an earlier note I recommended that we make M4 our API Freeze milestone.
> I'd like to clarify what this means and suggest how we should manage the API
> definition process.
>
> I got the following definition from Jeem:
>
> "We say that come API freeze, a component's API should be in shippable form
> and supportable in following releases. It many still need to be some
> polishing of the implementation underneath, but it should be just bug fixing
> and polishing. All specs and test suites should be in place.
>
> In Eclipse 3.0, we did the freezing in a couple of stages. We had an early
> cutoff for breaking API changes to pre-3.0 APIs. This kind of breaking API
> changes are always carefully reviewed and approved by PMC before proceeding.
> Most of the API changes are in fact non-breaking additions to existing APIs,
> or breaking changes to the new APIs that are still "settling". We expect
> developers to get all the API work done and in place before the API freeze.
> In practice, we get most of the way there, but there are still some API
> adjustments that are needed and we let them go in if there's a good reason
> to and they don't create problems. This is the slush stage of the API freeze
> process.
>
> As release draws near, a hard API freeze happens. We impose tight controls
> on all further API change by instituting a policy that proposed API changes
> of any sort (including trivial non-breaking ones) must be described by a
> detailed bug report and brought forward to the PMC. The PMC reviews these
> changes and weighs the potentially destabilizing effects of changing API at
> a late stage of the release cycle versus on the cost of leaving the API
> problem unaddressed. FYI, in 3.0 we approved 50 API changes after the API
> freeze; only one was proposed but later withdrawn. All of them were minor."
>
> Here are the guidelines I suggest we follow:
>
> 1. The most important reason to define an API is to provide stable
> interfaces to a "real" customer. Therefore, Rule #1 is that any WTP API must
> have at least one customer. The highest weight will be given to external
> customers. In priority order that means 1) Vendors that are planning to ship
> products based on WTP, 2) Eclipse projects that plan to use WTP, 3) other
> development projects that plan to use WTP, and 4) other WTP components that
> use WTP components.
>
> 2. If the only customer for an API is another WTP component then we have
> some flexibility. If there is only one other WTP component that needs the
> API, then we should look at merging the two components and defering the API.
> Remember that it is OK for plug-ins within a component to use internal
> packages.
>
> 3. We need to do a great job on the key APIs and defer definition for
> others to future releases when the project has more users and contributors.
> An API is a big committment. Any WTP 1.0 API MUST be preserved in future
> releases, so it's best for the project if we are very selective about what
> APIs go into WTP 1.0.
>
> 4. The M4 exit criteria for each API is:
> 1) at least one customer has been identified and has reviewed the
> API,
> 2) all Javadoc is complete,
> 3) at least one JUnit test exists for each method in the API,
> 4) a short overview document is complete.
> Note that it is enough for the JUnit to exist. It may fail if the API is
> not yet implemented. If these exit criteria are not met, then we either
> delay the milestone exit, or we pull the API.
>
> 5. After M4, any change to an API must be approved by the Planning Group.
> The input to the Planning Group is:
> 1) the component lead champions the change and has assessed the
> schedule impact,
> 2) the Architecture Group has reviewed the change and supports it.
>
> Comments?
>
> Arthur Ryman,
> Rational Desktop Tools Development
>
> phone: +1-905-413-3077, TL 969-3077
> assistant: +1-905-413-2411, TL 969-2411
> fax: +1-905-413-4920, TL 969-4920
> mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
> intranet: http://labweb.torolab.ibm.com/DRY6/
>
--
Gorkem Ercan
