| [eclipse.org-planning-council] Galileo Must-do's |
|
Hi, I have a few concerns with some of the must-do's. Specifically I can't commit to "Must have new & noteworthy for each milestone." I'd love to have those, and I'll try to do it, but I can't commit to doing it. I see they're a great thing to have. We generate release notes and for the time being, that's the best I can do. Please reconsider drawing the line more carefully between "it's really nice to have" verses "a coordinated build is just broken without them." It seems the only thing on the must do list that does seem essential. I can't commit to "Projects must use Eclipse message bundles unless there are technical reasons". EMF just work stand alone without Eclipse dependencies. EMF's APIs must support access to the translated and untranslated strings. I suppose those are technical reasons, so I'm off the hook. I'm concerned that the requirement that "Each project will provide basic capability/activity definitions to allow for their UI contributions to be hidden." will fill the space up with uncoordinated activities and if these aren't kept as separate features they will make it more difficult for vendors to ship products with their own capability definitions. I speak from past experience with folks who were unhappy with EMF's capability definitions. There is significant danger here that we will do more harm than good... I suggest we be very careful about how they are provided to ensure they can be easily removed... I cannot agree to "Must use ICU4J" Again, EMF must work stand alone without dependencies on Eclipse libraries. This is a technical reason so it will have to suffice. Please consider more carefully the black and white wording of this requirement. I.e., qualify it with "unless there are technical reasons". In general, the larger number bugzillas being opened aren't clear about must-do verses should-do. The bidi one specifically bothers me. Likely many of you have run into effectively unfixable bidi problems. EMF won't be addressing any bidi-specific problems. Month long debates in the past arrived at the conclusion that while it's very important to be able to develop bidi-enabled applications, making the development tools that work with primarily left-to-right scripts themselves be bidi-enabled is an uphill battle that few can afford and most unfortunate of all , from which all too few will benefit. Generally I think we have a good set of must do's. Regards, Ed |