Re: [epp-dev] EPP packages and the configuration problem

[Ian Skerrett <ian.skerrett@xxxxxxxxxxx>]

On 9/13/2010 10:54 AM, Eric Rizzo wrote:

Markus,
I read your (well written) comment on the bug, and I understand the path of reasoning that it follows. However, I want to point out that, even though it's a small percentage, the shared-install users WILL be annoyed at this and I suspect at least few of them will be quite vocal about it. We must learn a lesson from the Java 1.6u21 debacle, that lesson being the PR hit we can take, even when there are work-arounds and help available, can be sever.
Believe me, I'm a purist at heart, someone who usually values "cleanliness" above all else; the idea of including some bundles for no other purpose than to avoid a broken previous build is not pleasant. But I'm also a community advocate, and I don't want to have to answer yet another question about "why doesn't Eclipse work?" to users. The reputation hit shouldn't be discounted.
I don't understand the point about unknown side effects; don't we have time to thoroughly test the update scenarios so that we feel confident there are no unintended side effects?

It would appear we do know one side effect is lots of extra logged messages?   In general introducing something new, late in the release cycle always limits the amount of testing.  As we have seen with the Helios release, testing for update scenerios is not something we seem to do very well.  I also can't see that changing for SR1.

It seems we have two paths, one that is the "clean" approach, but leaves some users in the lurch and hopes that they will know where to go for help and have the/time patience to get it. The other option is less clean but is transparent to everyone. It's a difficult decision to choose between them, but I would opt for the one that is transparent so long as there's a way out of including the extra bundles forever (which, IIUC, there is since the latest p2 component won't need them).

I agree there does not appear to be one prefect option.  Not sure if I understand your view that including them is more 'transparent'.  Won't the extra logging message just prompt questions about why they occur?  Also, if we include them, don't we run the risk of people starting to assume they are there, so I am not sure if we can remove them at a later date?

FWIW, not including them seems cleaner.  We know what are the problems and can hopefully document them.  The alternative seems like it introduces a lot more risk, which seems unwise so late in the release cycle?

Ian

--
Ian Skerrett
Director of Marketing
Eclipse Foundation
Tel: 613-224-9461 ext 227
Blog: ianskerrett.wordpress.com
Twitter: IanSkerrett

Plan to Attend Eclipse Summit Europe
Nov. 2-4, 2010 Ludwigsburg Germany