[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] Galileo Must-do's
|
Rich,
Comments below.
Richard Gronback wrote:
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?
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 <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.
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. :-)
Regards,
Ed
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
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.
