RE: [eclipse.org-planning-council] Galileo Must-do's

["Richard Gronback" <Richard.Gronback@xxxxxxxxxxx>]

Hi Ed,

Some replies below...

Thanks,
Rich


-----Original Message-----
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx on behalf of Ed Merks
Sent: Mon 11/10/2008 8:13 PM
To: Cross project issues; Planning Council
Subject: [eclipse.org-planning-council] Galileo Must-do's
 
Hi,

I have a few concerns with some of the must-do's. 

[rcg] It was only a matter of time... ;-)  See how important it is to attend the face-to-face meetings?

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.

[rcg] It was a "bar raiser," though admittedly not much of a raise.  Frankly, the N&N requirement was inspired precisely by generated bugzilla lists, which most find less than helpful.  I hope you can find someone in your vibrant community to help out on this one... it really doesn't seem too high a bar, imho.

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.

[rcg] Agreed, sounds like you are off the hook.  To document, please enter the rationale in our project-specific bug for this requirement.

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...

[rcg] We saw this one as problematic, but kept it on the list as the pain has to begin sometime.  The requirement explicitly states they need to be delivered separately, so as to avoid the problem you mention.  We did discuss it. 

I cannot agree to "Must use ICU4J <http://wiki.eclipse.org/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".

[rcg] Same reply as above, I guess.

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.

[rcg] P1 == must-do, P2+ == should-do.  Feel free to close those should-dos you can't/won't complete as WONTFIX with a comment.

Generally I think we have a good set of must do's.

[rcg] Agreed.  Aside from the N&N item, which of the remaining P1s do you object to?

Regards,
Ed