Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Galileo Must-do's


Comments below.

Richard Gronback wrote:
Hi Ed,

Some replies below...


-----Original Message-----
From: on behalf of Ed Merks
Sent: Mon 11/10/2008 8:13 PM
To: Cross project issues; Planning Council
Subject: [] Galileo Must-do's

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?
Yes, I see that. If only I had deeper pockets and my spare time was more copious. :-P
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.
Even less helpful is no list of fixed bugzillas for each build.
 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.
Suppose for the sake of argument that I don't get around to doing this... Will the release train come to an end?
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.
Woo hoo.   There's no excuse like a good excuse.
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 <>" 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.
Two of three then. :-)
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?
Just the three I mentioned. And of course the 1st could easily be addresses with "lip service" to the process. After all, components like XSD are like to see not a single new or noteworthy thing. EMF Core's list seems to be sadly sparse as well. I suppose if I wrote a blog, I'd have content for a N&N too. :-)

_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top