Bugzilla – Full Text Bug Listing
| Summary: | specify criteria for graduating components from Mylyn incubator | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Steffen Pingel <steffen.pingel> |
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | greensopinion, hbershadskaya, robert.elves |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 254700 | ||
|
Description
Steffen Pingel
I would suggest a mini "release review" for the component that is moved as part of the regular Mylyn call. Here are a few things that would useful to look at: * Review of code quality, particularly API * Review of the documentation * Expected support overhead and maintainership (In reply to comment #1) > I would suggest a mini "release review" for the component that is moved as part > of the regular Mylyn call. Here are a few things that would useful to look at: > > * Review of code quality, particularly API > * Review of the documentation > * Expected support overhead and maintainership Sounds good to me, though a release review may take too long for a conference call. Perhaps the call would be a good forum for discussion around a release review, which might occur around a bugzilla ticket? Also a some questions: > * Review of code quality, particularly API * what are the criteria that determine 'good' versus 'poor' quality API? > * Review of the documentation * what kind of documentation? (javadoc or user documentation or both?) What do we expect to see in the documentation, and can it be measured using specific critera? without defining these things it will be difficult for developers to know what they should aim for... on the other hand, it'll make the review process 'lighter weight'. +1 for mini release review. > * what are the criteria that determine 'good' versus 'poor' quality API? Subjective opinion. For guidelines see Josh Bloch's Effective Java or his nice summary at: http://www.infoq.com/articles/API-Design-Joshua-Bloch > * what kind of documentation? (javadoc or user documentation or both?) That'll depend on the what component is. For user-facing stuff, at least a UI reference, but no need for tutorials, etc. For API, Javadoc on every public method, noting that we far prefer effort to go into API naming than long Javadocs. (In reply to comment #3) > For guidelines see Josh Bloch's Effective Java or his nice > summary at: http://www.infoq.com/articles/API-Design-Joshua-Bloch Very nice... I hadn't seen this one before. Overall I agree with a lightweight review. I had to ask the question because I want to be sure that everyone's on the same page. +1 for a mini release review +1 for starting the review on a bug report. Once the review has come to a point where all major concerns have been addressed or discussed I think it would still make sense to have a call to go over the results. For certain aspects such as a UI review I generally find it more efficient when it's done online. The Galileo requirements provide a list of criteria for Eclipse good practices that I think would be worth checking off for any graduating component: http://wiki.eclipse.org/Galileo_Simultaneous_Release#Requirements_For_Participation The review of the WikiText component can serve as an excellent reference for future reviews: http://wiki.eclipse.org/Mylyn/Incubator/WikiText/ReleaseReview |