SharedComponentVersioningGuidelinesReview

This page has been created to help track comments on the SharedComponentVersioningGuidelines. This is a distributed review process that has worked very well for me with previous and current distributed teams, and I thought we could try it here.

Each reviewer creates a new row in the table for each comment.

The Id column contains a unique identifier for the comment using your initials and a number, e.g. DVC1, DVC2, etc.
The Ref column contains a reference to what you are commenting on (e.g. "Section 2")
The Comment column is your comment
The Status column is used to track whether the comment is still open or closed
The Discussion column allows for a back-and-forth discussion. Each comment in this column is a new paragraph and is prefixed by the initials of the person adding to the discussion

If a particular item engenders a lot of discussion, you can create a new page for the discussion and link to it in the Discussion column.

The value of this approach is that each comment is tracked separately and can be resolved separately, without a huge long email thread where concerns and issues easily gets lost and everyone gets overwhelmed by email.

Comments on Second Version of Proposal

Ref

Comment

Status

Discussion

Comments on First Version of Proposal

Id	Ref	Comment	Status	Discussion
DJD1	`ProductVersionHolder`	I think PVH is overkill for a version on common code, why not a simple integer?	Open	DJD: Don't force commonality just because classes or concepts seem to be somewhat similar. JNB: PVH is overkill but an int is too simple. I'd rather see a feature mechanism. We should be concerned about coupling to common due to the versioning mechanism DVC: Jeremy created an addendum to this comment with an email, so I am moving the discussion of this item to SharedComponentVersioningGuidelinesReviewDjd1 DVC:Jeremy, I still have a question open to you about why String constants are preferred over int constants. Do you want to respond, or should I consider the matter closed? Dan, do you have anything remaining here, or are you satisfied?
TMNK1	Definition of module	I'm not sure what module means in this context ... The word module was used in paper of derby as next. http://db.apache.org/derby/papers/derby_arch.html#Modules Are they, which mentioned in the paper and in this discussion, refer same existance ?	Reopened ?	DVC: You're right, Tomohito, my use of module here is confusing. I will pick a new term and define it clearly in the context of this discussion. How about "shareable component?" TMNK: Well ... I think we have not fiugred out what it is , and impossible to name it now .... (I imagine that it may be library , however, just imagining and too unreliable thinking .... I think answer of TMNK2 is needed for naming correctly .) DVC:I tried a definition of "shared component" in WhatIsTheCodeToBeShared, please see what you think TMNK:I don't think this is solved yet. Working on ListOfSharedComponent and pages linked from that would be needed ....
TMNK2	What is being shared	What is the code to be shared as module in this discussion ? If it were just java apis, they are shared already ....	Resolved	DVC: I'm not sure what you mean when you say they are shared already. For example, as it stands today, the internationalization code and messages in the engine can not be shared with the network client. Also, the DRDA network code can not be shared between server and client. TMNK:I think new page WhatIsTheCodeToBeShared is needed to continue discussing .... DVC: I responded to your questions, please take a look

SharedComponentVersioningGuidelinesReview (last edited 2009-09-20 22:12:30 by localhost)