[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[mylyn-dev] Re: Policies for EPP
|
I made sure to stay completely out of the discussion on what to include
in EPP because I knew that Mylyn was being considered, and did not want
to bias EPP's selection process with the fact that I thought that
inclusion of Mylyn would be beneficial it's adoption. This message is
not intended to define how projects should be selected, just to quickly
relate sopme Mylyn's experiences with becoming a part of EPP.
First, when we heard that we would be included, we had to quickly make
the decision whether we were ready for this this to happen. Our
decision to go ahead was entirely based on whether the way the tool had
hardened around its early adopters would scale to the majority of
Eclipse users. Here is what we considered:
* Leading up to Mylyn 1.0 (2006-12-11) we resolved 1791 bugs, dominated
by early adopter feedback.
* As Denis points out the 1.0 release raised our visibility sufficiently
for us to harden the tool around the next round of early adopter
feedback from the adoption of Mylyn 1.0. That came much quicker, and we
resolved 951 bugs for Mylyn 2.0 (Europa).
We decided that this was sufficient usage feedback for EPP, which launch
edus from an early adopter community of at least tens of thousands, to a
much larger community with a very different user profile and
expectations than early adopters. What I have learned is that we
barely squeezed by in terms of meeting the bar in terms of overall
quality and usability, even though we worked like crazy to both get more
usage feedback between 1.0 and 2.0 and resolve all the key bugs and UI
problems.
With the EPP packagings users' expectations are dramatically different.
Consider the following article, which contains by far the most
negative comments I have seen on Mylyn to date:
http://www.infoq.com/news/2007/10/mylyn
Note that the problems cited there turned out not to be related to Mylyn
failures. Some of the users were seeing innocuous warnings in their log
related to Mylyn, the other user had hundreds of resources out of synch
with their filesystem, which was unsurprisingly confusing Subclipse.
But to the average user none of this matters. If there is something new
or weird with their IDE, and something fails (e.g. wrong MaxPermSize
setting in Eclipse 3.3.1) they will simply blame or flame about the new
thing. Note that Mylyn is particularly susceptible to this because its
Task-Focused UI touches a significant portion of the Eclipse UI.
While we're actually in a good state right now, and afaik there hasn't
been any other EPP related fall-out anywhere near as bad as the
MaxPermSize Platform problem with Mylyn or other packagings, I do think
that we need to consider such issues further in terms of EPP policies:
http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01049.html
Mik
Denis Roy wrote:
Scott Lewis wrote:
But this is precisely the point of my response to Ian's previous
post...this is naturally based upon your assumptions about what the
new user 'needs'.
Actually, I see a correlation between the EPP packages and the top-10
popular projects on the downloads page [1]. Aside from BIRT and TPTP,
most of the popular projects are either a complement to an EPP package
or the core component of a package. Mylyn made the top-10 when 1.0 was
released some time ago. PDT wasn't 1.0 until recently, and I can see how
a PHP Developer package could be something useful for our users.
So it appears to me that the EPP packages are based on the reality of
what the new user is likely to 'want', taking into account current
download trends and project popularity.
[1] http://www.eclipse.org/downloads/
