Home » Archived » EPP » Policies for EPP
|
| Re: Policies for EPP [message #6337 is a reply to message #6320] |
Tue, 23 October 2007 16:16   |
Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Ian,
Although I applaud an effort to make these criteria public
(transparent), I question whether these/this set of policies make the
process more 'open'. Basically, as below IMHO it's a set of (quite
restrictive) exclusion criteria...which doesn't seem very open to me.
For example:
'Small number' (2): basically a project therefore can't get in because
you weren't in the initial set of 4? And 'strong feedback from the
community'...what/which community? Committers? Stragegic members? ?
'Size' (3): Size of existing packages small: so if you have anything
above...what...50K of code/3 bundles that's too big? What is small?
Download size, runtime size, # bundles...?
'Release train only': (4) Naturally, that excludes quite a number of
projects (all those that cannot meet all the release train requirements
as well).
'Discussion' (5): What's the point of discussion if 2, 3, 4, 6 won't
allow any changes?
And WRT 7, how/does this overlap with/duplicate the Equinox p2 work
(which is essentially creating/has created such a framework as well)?
Scott
Ian Skerrett wrote:
> I thought it might be useful for the EPP project to have a set of policies
> that we use to determine that content of the packages. The goal is that we
> all agree to an approach for making decisions on the package content. This
> will hopefully make the project more open and transparent in the decision
> making process.
>
> Here is a draft set of policies that I think might make sense. Thoughts?
>
>
> 1.. The goal of the EPP packages is to improve the initial out-of-box
> experience for an Eclipse user.
> 2.. EPP intends to keep the number of packages the project maintains to a
> very small number. The initial 4 packages were defined in the original
> project proposal and we don't intend to add additional packages unless we
> receive strong feedback from the community.
> 3.. We want to keep the size of the existing packages as small as
> possible. The existing packages are defined based on the profiles of a
> target user. The philosophy is to provide a solution that addresses the
> basic needs of the majority of the target user population. We are not
> trying to solve everyone's requirements.
> 4.. EPP will update the content of each package to coincide with the
> annual release train. We will not change the contents of the packages
> during the year. During the Fall and Spring maintenance release we will
> only update the packages with the new releases from the existing projects.
> 5.. The package content update will be discussed in an open and
> transparent way on the EPP newsgroups. Everyone in the Eclipse community is
> welcomed to provide feedback. The EPP committers will make the final
> decision on the package content.
> 6.. A project that is included in an EPP package must have the following:
> 1) must be part of the annual release train, 2) be at least a 1.0 release,
> 3) must have a stable and reliable build and 4) should have provide a
> minimal set of features so the EPP package can remain small.
> 7.. EPP will be creating frameworks to allow others to create other
> packages. The Eclipse community is encouraged to take advantage of these
> frameworks to create their own package for different user profiles.
>
>
|
|
| |
| Re: Policies for EPP [message #6372 is a reply to message #6337] |
Wed, 24 October 2007 16:07 |
| Eclipse User |
|
|
|
Originally posted by: mknauer.innoopract.com
Hi Scott,
let me write down some of my thoughts here:
* 'Small number' -> We tried really hard to present the packages on the
donwload page in a way which allows a new user to get what he/she needs. I
think it is still too complicated and every additional package adds more
complexity to the selection process. Maybe we can remove one of the
packages and replace it with another one, but to avoid more confusion this
can only be done with the Ganymede release.
* 'Getting in' -> Again, I don't like to change the existing packages,
because it would be hard to explain to the users, why these packages have
changed ('I user the XY-europa-fall package, now I switched to the
XY-europa-winter package and this feature is missing')
But with Ganymede we can adjust the package content (keeping in mind that it
is easy to add something, but hard to remove anything... so we need to be
very conservative)
* 'Community feedback' -> Maybe we need to specify this more clearly... but
this is one reason for this discussion on the newsgroup.
* 'Small' -> IMHO this is the download size (and only the download size). I
was really surprised that the (small) Java package is on the top position
of every download statistic.
* 'Release train only' -> The likeliness that a project from the release
train delivers something stable, well tested, etc. is higher than that of
other projects. Based on that assumption it is a natural decision to use
this as a prerequisite for building stable and reliable packages.
* 'Discussion' -> We are trying to get feedback... and I am sure you will
agree that we need some policy/instructions for a project that wants to be
part of an EPP package.
Markus
Scott Lewis wrote:
> Hi Ian,
>
> Although I applaud an effort to make these criteria public
> (transparent), I question whether these/this set of policies make the
> process more 'open'. Basically, as below IMHO it's a set of (quite
> restrictive) exclusion criteria...which doesn't seem very open to me.
>
> For example:
>
> 'Small number' (2): basically a project therefore can't get in because
> you weren't in the initial set of 4? And 'strong feedback from the
> community'...what/which community? Committers? Stragegic members? ?
> 'Size' (3): Size of existing packages small: so if you have anything
> above...what...50K of code/3 bundles that's too big? What is small?
> Download size, runtime size, # bundles...?
> 'Release train only': (4) Naturally, that excludes quite a number of
> projects (all those that cannot meet all the release train requirements
> as well).
> 'Discussion' (5): What's the point of discussion if 2, 3, 4, 6 won't
> allow any changes?
>
> And WRT 7, how/does this overlap with/duplicate the Equinox p2 work
> (which is essentially creating/has created such a framework as well)?
>
> Scott
>
>
> Ian Skerrett wrote:
>> I thought it might be useful for the EPP project to have a set of
>> policies
>> that we use to determine that content of the packages. The goal is that
>> we
>> all agree to an approach for making decisions on the package content.
>> This will hopefully make the project more open and transparent in the
>> decision making process.
>>
>> Here is a draft set of policies that I think might make sense.
>> Thoughts?
>>
>>
>> 1.. The goal of the EPP packages is to improve the initial out-of-box
>> experience for an Eclipse user.
>> 2.. EPP intends to keep the number of packages the project maintains to
>> a
>> very small number. The initial 4 packages were defined in the original
>> project proposal and we don't intend to add additional packages unless we
>> receive strong feedback from the community.
>> 3.. We want to keep the size of the existing packages as small as
>> possible. The existing packages are defined based on the profiles of a
>> target user. The philosophy is to provide a solution that addresses the
>> basic needs of the majority of the target user population. We are not
>> trying to solve everyone's requirements.
>> 4.. EPP will update the content of each package to coincide with the
>> annual release train. We will not change the contents of the packages
>> during the year. During the Fall and Spring maintenance release we will
>> only update the packages with the new releases from the existing
>> projects.
>> 5.. The package content update will be discussed in an open and
>> transparent way on the EPP newsgroups. Everyone in the Eclipse community
>> is
>> welcomed to provide feedback. The EPP committers will make the final
>> decision on the package content.
>> 6.. A project that is included in an EPP package must have the
>> following:
>> 1) must be part of the annual release train, 2) be at least a 1.0
>> release, 3) must have a stable and reliable build and 4) should have
>> provide a minimal set of features so the EPP package can remain small.
>> 7.. EPP will be creating frameworks to allow others to create other
>> packages. The Eclipse community is encouraged to take advantage of
>> these frameworks to create their own package for different user profiles.
>>
>>
|
|
|
| Re: Policies for EPP [message #6391 is a reply to message #6355] |
Wed, 24 October 2007 16:42 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Ian,
Ian Skerrett wrote:
>> Although I applaud an effort to make these criteria public
>> (transparent), I question whether these/this set of policies make the
>> process more 'open'. Basically, as below IMHO it's a set of (quite
>> restrictive) exclusion criteria...which doesn't seem very open to me.
>
> Scott, when I said 'open' I was not thinking that the packages would be
> open to any project being included.
I'm not saying 'open in that any project must being included'. I'm
saying 'open about what it takes to participate' (and, of course,
*possible* to participate...which is certainly not open).
The 'small as possible' is a policy which in the limit essentially
excludes *everything* other than what EPP deems 'necessary'...which I
don't think is acceptable for a community resource (and, as such an
important distribution path for all EF projects).
Also, this rule obviously doesn't apply to the existing projects in the
existing profiles...the SDK is huge...and they can put in anything they
want and have it included in all subsequent EPP distributions...as can
WTP and others. If smaller is a driving requirement for distribution,
then why wouldn't/shouldn't such a rule be applied to the existing EPP
projects?
Finally, I understood EPP would make available multiple profiles...so if
that's the case then why not have other/more profiles that include
new/other projects?
In fact, I believe the EPP
> packages should be kept as small as possible and only add new
> features/projects if there is a really good reason.
This is your judgment...not the community's. I appreciate and generally
agree with the desire to keep things small and simple for users (and
frankly my project would not have any problems with this rule). But of
course all projects (and their respective communities) can also think of
'really good reasons' to add their work...and they would be right, of
course.
This is because I
> believe if the EPP packages become a 'catch-all' for all Eclipse
> projects, they will become too big and meaningless for the end user.
As with Eclipse (platform) itself?
I think this is a specious argument...precisely because it's based upon
so many assumptions about the 'end user'...i.e. that they are a user
that is looking for an IDE, for java development, etc., etc. Perhaps
valid/appropriate assumption for existing tools businesses, but not an
accurate reflection of where Eclipse is going.
I agree that things should be made as simple as possible for usability
across all users, but IMHO that's the hard part...for all the projects
(and for the EF).
>
> However, I'd like to stress this is just my opinion so you and others
> should be encouraged to comment.
OK, I did.
Scott
|
|
|
| Re: Policies for EPP [message #6410 is a reply to message #6372] |
Wed, 24 October 2007 17:18 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Markus,
Markus Knauer wrote:
> Hi Scott,
>
> let me write down some of my thoughts here:
>
> * 'Small number' -> We tried really hard to present the packages on the
> donwload page in a way which allows a new user to get what he/she needs.
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'.
I'm not saying you/EPP/whoever didn't do a decent job of it for Europa,
but rather for a process to be 'open' it has to include more than your
(Ian's, Markus's or whoever's) judgment (at least for me).
<stuff deleted>
>
> * 'Getting in' -> Again, I don't like to change the existing packages,
> because it would be hard to explain to the users, why these packages have
> changed ('I user the XY-europa-fall package, now I switched to the
> XY-europa-winter package and this feature is missing')
> But with Ganymede we can adjust the package content (keeping in mind that it
> is easy to add something, but hard to remove anything... so we need to be
> very conservative)
I think saying that things can't change because it would be 'hard to
explain to users' doesn't really work for me. Why? Because new
software *is* change. If the EF (and it's associated projects) want to
have 'innovation networks', then things must change. Like a shark, if
it's not moving forward, it's dead :).
I guess I'm not so worried about users and change as you are. Change is
constant (especially in sw dev tools). I don't think that is avoidable.
Now I think it's possible to make it simpler for users to deal with
change, but I thought that's what EPP was really setup to do.
>
> * 'Community feedback' -> Maybe we need to specify this more clearly... but
> this is one reason for this discussion on the newsgroup.
>
> * 'Small' -> IMHO this is the download size (and only the download size). I
> was really surprised that the (small) Java package is on the top position
> of every download statistic.
small Java package?
Of course JDT is in the top position in every download statistic...it's
where Eclipse started out and where it achieved its popularity. I don't
think this is surprising or even informative.
RE: download size...OK. But as I said in previous note, if (download)
size is the metric of importance then why wouldn't/shouldn't this be
applied to existing EPP packages as well?
Just for reference ECF's 2 core plugins total ~110K. Further, these and
2 other ECF plugins (totalling about 400K) will be in the core Equinox
distribution for 3.4 (to support the Equinox p2 work).
>
> * 'Release train only' -> The likeliness that a project from the release
> train delivers something stable, well tested, etc. is higher than that of
> other projects. Based on that assumption it is a natural decision to use
> this as a prerequisite for building stable and reliable packages.
I agree that the release train is more likely to deliver something
stable, well-tested, etc...at least in theory.
I don't have major problems myself with this particular policy idea, but
that's because my project is already part of the release train. I think
that other projects might...probably because they don't even have the
resources to do the things necessary to participate in Ganymede...not to
mention do additional things to get included in EPP.
BTW, why doesn't EPP just become
>
> * 'Discussion' -> We are trying to get feedback... and I am sure you will
> agree that we need some policy/instructions for a project that wants to be
> part of an EPP package.
Yes, that is my major point...EPP certainly does need
policy/instructions for a project that wants to be part of an EPP
package. But those instructions will be useless/meaningless to projects
if it is not possible for them to do anything that will lead to
inclusion in EPP.
Scott
|
|
| |
| Re: Policies for EPP [message #6448 is a reply to message #6429] |
Thu, 25 October 2007 14:42 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Ian Skerrett wrote:
>> I think saying that things can't change because it would be 'hard to
>> explain to users' doesn't really work for me. Why? Because new software
>> *is* change. If the EF (and it's associated projects) want to have
>> 'innovation networks', then things must change. Like a shark, if it's not
>> moving forward, it's dead :).
>
> Scott, there is lots of change that happens in Eclipse. We are just talking
> about the packages that EPP is producing.
Of course I understand that. But if the projects don't have a
distribution mechanism, that positive change/innovation will never reach
anyone.
>> I guess I'm not so worried about users and change as you are. Change is
>> constant (especially in sw dev tools). I don't think that is avoidable.
>> Now I think it's possible to make it simpler for users to deal with
>> change, but I thought that's what EPP was really setup to do.
>
> I agree with Markus. The packages need to be consistent from one release
> to the next or we run the risk of confusing people. Change will happen but
> at a much slower pace than in other parts of the Eclipse community.
I think this is simply a poor judgment, and based upon user assumptions
that are biased away from innovation and toward 'business predictability'.
>
>
>> Yes, that is my major point...EPP certainly does need policy/instructions
>> for a project that wants to be part of an EPP package. But those
>> instructions will be useless/meaningless to projects if it is not possible
>> for them to do anything that will lead to inclusion in EPP.
>
> I actually think most projects will NOT be included in the EPP packages. I
> think this is where you and I probably disagree.
Yes.
EPP will fail if it starts
> to include too much stuff.
I think this is wrong. EPP will fail if it doesn't deliver what people
want and the projects need to survive and flourish.
They need to include the base functionality but
> encourage the use of update sites to get additional project functionality.
Encouraging update sites is fine/good, but as the Europa download
numbers show, EPP is/will be responsible for a lot of distribution...to
the detriment of the projects that cannot participate (because you say
they can't).
>
> If EPP is viewed as the primary distribution channel for Eclipse projects
> then we will fail; in my opinion.
I disagree.
I suppose this means all the second class projects will have to wait for
p2 tech to get additional distribution through EF. A shame.
Scott
|
|
|
| Re: Policies for EPP [message #6466 is a reply to message #6448] |
Thu, 25 October 2007 16:08 |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Just to chime in with a neutral outsider's opinion:
I agree mostly with the policies as originally posted; specifically with
the idea that EPP packages are more carefully/slowly/strictly evolved
than the general Eclipse ecosystem. I'm coming at it as a person who
spends countless hours answering questions on the newsgroups, many of
them from newbies. From that perspective, the primary benefits I am
hoping to get from EPP are simplicity, ease, and safety. I'm still
waiting for an installer for the ease part and some of the safety part,
but the simplicity part has been taken care of by (careful, with
community feedback) selection of a small number of general-purpose
packages. I would not want to see the Downloads page polluted with a
menagerie of choices that need more than a blurb of explanation.
Perhaps a compromise would be to allow EPP to be a little more broad in
its acceptance policies, but to NOT include all available packages on
the default Downloads page.
Eric
Scott Lewis wrote:
> Ian Skerrett wrote:
>>> I think saying that things can't change because it would be 'hard to
>>> explain to users' doesn't really work for me. Why? Because new
>>> software *is* change. If the EF (and it's associated projects) want
>>> to have 'innovation networks', then things must change. Like a
>>> shark, if it's not moving forward, it's dead :).
>>
>> Scott, there is lots of change that happens in Eclipse. We are just
>> talking about the packages that EPP is producing.
>
>
> Of course I understand that. But if the projects don't have a
> distribution mechanism, that positive change/innovation will never reach
> anyone.
>
>
>>> I guess I'm not so worried about users and change as you are. Change
>>> is constant (especially in sw dev tools). I don't think that is
>>> avoidable. Now I think it's possible to make it simpler for users to
>>> deal with change, but I thought that's what EPP was really setup to do.
>>
>> I agree with Markus. The packages need to be consistent from one
>> release to the next or we run the risk of confusing people. Change
>> will happen but at a much slower pace than in other parts of the
>> Eclipse community.
>
>
> I think this is simply a poor judgment, and based upon user assumptions
> that are biased away from innovation and toward 'business predictability'.
>
>>
>>
>>> Yes, that is my major point...EPP certainly does need
>>> policy/instructions for a project that wants to be part of an EPP
>>> package. But those instructions will be useless/meaningless to
>>> projects if it is not possible for them to do anything that will lead
>>> to inclusion in EPP.
>>
>> I actually think most projects will NOT be included in the EPP
>> packages. I think this is where you and I probably disagree.
>
> Yes.
>
> EPP will fail if it starts
>> to include too much stuff.
>
>
> I think this is wrong. EPP will fail if it doesn't deliver what people
> want and the projects need to survive and flourish.
>
>
> They need to include the base functionality but
>> encourage the use of update sites to get additional project
>> functionality.
>
>
> Encouraging update sites is fine/good, but as the Europa download
> numbers show, EPP is/will be responsible for a lot of distribution...to
> the detriment of the projects that cannot participate (because you say
> they can't).
>
>>
>> If EPP is viewed as the primary distribution channel for Eclipse
>> projects then we will fail; in my opinion.
>
>
> I disagree.
>
> I suppose this means all the second class projects will have to wait for
> p2 tech to get additional distribution through EF. A shame.
>
> Scott
|
|
| | | |
| Re: Policies for EPP [message #6543 is a reply to message #6486] |
Thu, 25 October 2007 22:55 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Ian Skerrett wrote:
>> Encouraging update sites is fine/good, but as the Europa download numbers
>> show, EPP is/will be responsible for a lot of distribution...to the
>> detriment of the projects that cannot participate (because you say they
>> can't).
>
> Sorry I don't buy that EPP is the only distribution mechanism and if you are
> not included it is to the projects detriment.
I did not say that EPP was the only distribution mechanism provided by
EF. But it clearly is emphasized (and as the numbers show this is
having the intended effect).
Only necessary evidence: http://www.eclipse.org/downloads/
That is like saying if you
> are not included in the Platform project, you have no hope of success.
I didn't say this either. *Not* getting distribution through the EF
website makes it more difficult for projects to get accepted and used.
This is to their detriment.
and
> lots of projects have proven that is not true. In fact, probably the only
> project that has benefited from being included in EPP is Mylyn.
I'm not sure why you say this. Although I wouldn't doubt that Mylyn has
benefited tremendously (simply because it's the least well known/newest
of the projects included in the EPP distributions), this doesn't mean
that it's the only project that has benefited (?).
I would say more distribution (for any project) is better. Less
distribution is a detriment. I would guess that the effects either way
are larger for projects that are not as well established (i.e. newer).
And, BTW, I'm in favor of EPP allowing other packages to be constructed,
but it currently doesn't seem possible.
>
> I really think you are trying to make EPP into something that it wasn't
> intended to be.
What was it intended to be then? I *don't* expect that it is intended
to be a way for a few favored projects to get greater distribution.
But rather:
1. Create entry level downloads based on defined user profiles
What about other user profiles (like, for example, team development, or
build/deploy master)? Seems like these are in scope. If not, why?
2. Provide an installer that improves the install experience of new
users of Eclipse
'Eclipse', last time I checked, includes projects not participating in
EPP (currently). At least I believe it should (or, more accurately, it
should be possible).
3. Provide a platform that allows the creation of packages (zip/tar
downloads) from an update site.
OK, I for one would be happy to do this. Can I?
Scott
|
|
|
| Re: Policies for EPP [message #6562 is a reply to message #6524] |
Thu, 25 October 2007 22:58 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Denis,
I would say that using download statistics as a measure of user 'want'
is pretty tenuous. Obviously, it systematically excludes the new (and
innovative).
Scott
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/
>
|
|
|
| Re: Policies for EPP [message #6580 is a reply to message #6505] |
Sat, 27 October 2007 09:46 |
| Eclipse User |
|
|
|
Originally posted by: mknauer.innoopract.com
Ian Skerrett wrote:
>> Just to chime in with a neutral outsider's opinion:
>
> Thank you for doing so. I actually wish more people would express their
> opinion and you certainly are not an outsider.
>
>>
>> Perhaps a compromise would be to allow EPP to be a little more broad in
>> its acceptance policies, but to NOT include all available packages on the
>> default Downloads page.
>
> The goal is that EPP will produce a set of framework that other people can
> use to build their own packages. We then create a 'interesting packages'
> page from the download page that lists all the available packages. Those
> packages would be created and tested outside of EPP, so they would not
> follow these policies.
And in the end the download stats of those 'interesting packages' would be
another input source of what people want. That's very worthfull information
to adjust and to change the EPP package content accordingly.
But if we are going to provide such a page, we have to ensure that it
scales. How do you find the best available package, if there are a few
hundreds of them? How do we distribute this huge amount of data?
I expect that many of this kind of questions need to be solved, but it
definitely is worth the effort. Maybe in cooperation with Bjorn's plan of a
standard project download page?
Markus
|
|
|
| Re: Policies for EPP [message #7339 is a reply to message #6524] |
Fri, 02 November 2007 21:27 |
| Eclipse User |
|
|
|
Originally posted by: beatmik.acm.org
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-co uncil/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/
|
|
|
| Re: Policies for EPP [message #7351 is a reply to message #7339] |
Wed, 07 November 2007 21:56 |
 Eclipse Webmaster
Messages: 607343
Registered: July 2009 |
Senior Member |
|
|
Very insightful, thanks.
D.
Mik Kersten wrote:
> 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-co uncil/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/
--
Eclipse WebMaster - webmaster@eclipse.org
Questions? Consult the WebMaster FAQ at
http://wiki.eclipse.org/index.php/Webmaster_FAQ
View my status at http://wiki.eclipse.org/index.php/WebMaster
|
|
|
| Re: Policies for EPP [message #575240 is a reply to message #6320] |
Tue, 23 October 2007 16:16 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ian,
Although I applaud an effort to make these criteria public
(transparent), I question whether these/this set of policies make the
process more 'open'. Basically, as below IMHO it's a set of (quite
restrictive) exclusion criteria...which doesn't seem very open to me.
For example:
'Small number' (2): basically a project therefore can't get in because
you weren't in the initial set of 4? And 'strong feedback from the
community'...what/which community? Committers? Stragegic members? ?
'Size' (3): Size of existing packages small: so if you have anything
above...what...50K of code/3 bundles that's too big? What is small?
Download size, runtime size, # bundles...?
'Release train only': (4) Naturally, that excludes quite a number of
projects (all those that cannot meet all the release train requirements
as well).
'Discussion' (5): What's the point of discussion if 2, 3, 4, 6 won't
allow any changes?
And WRT 7, how/does this overlap with/duplicate the Equinox p2 work
(which is essentially creating/has created such a framework as well)?
Scott
Ian Skerrett wrote:
> I thought it might be useful for the EPP project to have a set of policies
> that we use to determine that content of the packages. The goal is that we
> all agree to an approach for making decisions on the package content. This
> will hopefully make the project more open and transparent in the decision
> making process.
>
> Here is a draft set of policies that I think might make sense. Thoughts?
>
>
> 1.. The goal of the EPP packages is to improve the initial out-of-box
> experience for an Eclipse user.
> 2.. EPP intends to keep the number of packages the project maintains to a
> very small number. The initial 4 packages were defined in the original
> project proposal and we don't intend to add additional packages unless we
> receive strong feedback from the community.
> 3.. We want to keep the size of the existing packages as small as
> possible. The existing packages are defined based on the profiles of a
> target user. The philosophy is to provide a solution that addresses the
> basic needs of the majority of the target user population. We are not
> trying to solve everyone's requirements.
> 4.. EPP will update the content of each package to coincide with the
> annual release train. We will not change the contents of the packages
> during the year. During the Fall and Spring maintenance release we will
> only update the packages with the new releases from the existing projects.
> 5.. The package content update will be discussed in an open and
> transparent way on the EPP newsgroups. Everyone in the Eclipse community is
> welcomed to provide feedback. The EPP committers will make the final
> decision on the package content.
> 6.. A project that is included in an EPP package must have the following:
> 1) must be part of the annual release train, 2) be at least a 1.0 release,
> 3) must have a stable and reliable build and 4) should have provide a
> minimal set of features so the EPP package can remain small.
> 7.. EPP will be creating frameworks to allow others to create other
> packages. The Eclipse community is encouraged to take advantage of these
> frameworks to create their own package for different user profiles.
>
>
|
|
| |
| Re: Policies for EPP [message #575319 is a reply to message #6337] |
Wed, 24 October 2007 16:07 |
|
Hi Scott,
let me write down some of my thoughts here:
* 'Small number' -> We tried really hard to present the packages on the
donwload page in a way which allows a new user to get what he/she needs. I
think it is still too complicated and every additional package adds more
complexity to the selection process. Maybe we can remove one of the
packages and replace it with another one, but to avoid more confusion this
can only be done with the Ganymede release.
* 'Getting in' -> Again, I don't like to change the existing packages,
because it would be hard to explain to the users, why these packages have
changed ('I user the XY-europa-fall package, now I switched to the
XY-europa-winter package and this feature is missing')
But with Ganymede we can adjust the package content (keeping in mind that it
is easy to add something, but hard to remove anything... so we need to be
very conservative)
* 'Community feedback' -> Maybe we need to specify this more clearly... but
this is one reason for this discussion on the newsgroup.
* 'Small' -> IMHO this is the download size (and only the download size). I
was really surprised that the (small) Java package is on the top position
of every download statistic.
* 'Release train only' -> The likeliness that a project from the release
train delivers something stable, well tested, etc. is higher than that of
other projects. Based on that assumption it is a natural decision to use
this as a prerequisite for building stable and reliable packages.
* 'Discussion' -> We are trying to get feedback... and I am sure you will
agree that we need some policy/instructions for a project that wants to be
part of an EPP package.
Markus
Scott Lewis wrote:
> Hi Ian,
>
> Although I applaud an effort to make these criteria public
> (transparent), I question whether these/this set of policies make the
> process more 'open'. Basically, as below IMHO it's a set of (quite
> restrictive) exclusion criteria...which doesn't seem very open to me.
>
> For example:
>
> 'Small number' (2): basically a project therefore can't get in because
> you weren't in the initial set of 4? And 'strong feedback from the
> community'...what/which community? Committers? Stragegic members? ?
> 'Size' (3): Size of existing packages small: so if you have anything
> above...what...50K of code/3 bundles that's too big? What is small?
> Download size, runtime size, # bundles...?
> 'Release train only': (4) Naturally, that excludes quite a number of
> projects (all those that cannot meet all the release train requirements
> as well).
> 'Discussion' (5): What's the point of discussion if 2, 3, 4, 6 won't
> allow any changes?
>
> And WRT 7, how/does this overlap with/duplicate the Equinox p2 work
> (which is essentially creating/has created such a framework as well)?
>
> Scott
>
>
> Ian Skerrett wrote:
>> I thought it might be useful for the EPP project to have a set of
>> policies
>> that we use to determine that content of the packages. The goal is that
>> we
>> all agree to an approach for making decisions on the package content.
>> This will hopefully make the project more open and transparent in the
>> decision making process.
>>
>> Here is a draft set of policies that I think might make sense.
>> Thoughts?
>>
>>
>> 1.. The goal of the EPP packages is to improve the initial out-of-box
>> experience for an Eclipse user.
>> 2.. EPP intends to keep the number of packages the project maintains to
>> a
>> very small number. The initial 4 packages were defined in the original
>> project proposal and we don't intend to add additional packages unless we
>> receive strong feedback from the community.
>> 3.. We want to keep the size of the existing packages as small as
>> possible. The existing packages are defined based on the profiles of a
>> target user. The philosophy is to provide a solution that addresses the
>> basic needs of the majority of the target user population. We are not
>> trying to solve everyone's requirements.
>> 4.. EPP will update the content of each package to coincide with the
>> annual release train. We will not change the contents of the packages
>> during the year. During the Fall and Spring maintenance release we will
>> only update the packages with the new releases from the existing
>> projects.
>> 5.. The package content update will be discussed in an open and
>> transparent way on the EPP newsgroups. Everyone in the Eclipse community
>> is
>> welcomed to provide feedback. The EPP committers will make the final
>> decision on the package content.
>> 6.. A project that is included in an EPP package must have the
>> following:
>> 1) must be part of the annual release train, 2) be at least a 1.0
>> release, 3) must have a stable and reliable build and 4) should have
>> provide a minimal set of features so the EPP package can remain small.
>> 7.. EPP will be creating frameworks to allow others to create other
>> packages. The Eclipse community is encouraged to take advantage of
>> these frameworks to create their own package for different user profiles.
>>
>>
--
Twitter: @mknauer23 and @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: Policies for EPP [message #575334 is a reply to message #6355] |
Wed, 24 October 2007 16:42 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ian,
Ian Skerrett wrote:
>> Although I applaud an effort to make these criteria public
>> (transparent), I question whether these/this set of policies make the
>> process more 'open'. Basically, as below IMHO it's a set of (quite
>> restrictive) exclusion criteria...which doesn't seem very open to me.
>
> Scott, when I said 'open' I was not thinking that the packages would be
> open to any project being included.
I'm not saying 'open in that any project must being included'. I'm
saying 'open about what it takes to participate' (and, of course,
*possible* to participate...which is certainly not open).
The 'small as possible' is a policy which in the limit essentially
excludes *everything* other than what EPP deems 'necessary'...which I
don't think is acceptable for a community resource (and, as such an
important distribution path for all EF projects).
Also, this rule obviously doesn't apply to the existing projects in the
existing profiles...the SDK is huge...and they can put in anything they
want and have it included in all subsequent EPP distributions...as can
WTP and others. If smaller is a driving requirement for distribution,
then why wouldn't/shouldn't such a rule be applied to the existing EPP
projects?
Finally, I understood EPP would make available multiple profiles...so if
that's the case then why not have other/more profiles that include
new/other projects?
In fact, I believe the EPP
> packages should be kept as small as possible and only add new
> features/projects if there is a really good reason.
This is your judgment...not the community's. I appreciate and generally
agree with the desire to keep things small and simple for users (and
frankly my project would not have any problems with this rule). But of
course all projects (and their respective communities) can also think of
'really good reasons' to add their work...and they would be right, of
course.
This is because I
> believe if the EPP packages become a 'catch-all' for all Eclipse
> projects, they will become too big and meaningless for the end user.
As with Eclipse (platform) itself?
I think this is a specious argument...precisely because it's based upon
so many assumptions about the 'end user'...i.e. that they are a user
that is looking for an IDE, for java development, etc., etc. Perhaps
valid/appropriate assumption for existing tools businesses, but not an
accurate reflection of where Eclipse is going.
I agree that things should be made as simple as possible for usability
across all users, but IMHO that's the hard part...for all the projects
(and for the EF).
>
> However, I'd like to stress this is just my opinion so you and others
> should be encouraged to comment.
OK, I did.
Scott
|
|
|
| Re: Policies for EPP [message #575351 is a reply to message #6372] |
Wed, 24 October 2007 17:18 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Markus,
Markus Knauer wrote:
> Hi Scott,
>
> let me write down some of my thoughts here:
>
> * 'Small number' -> We tried really hard to present the packages on the
> donwload page in a way which allows a new user to get what he/she needs.
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'.
I'm not saying you/EPP/whoever didn't do a decent job of it for Europa,
but rather for a process to be 'open' it has to include more than your
(Ian's, Markus's or whoever's) judgment (at least for me).
<stuff deleted>
>
> * 'Getting in' -> Again, I don't like to change the existing packages,
> because it would be hard to explain to the users, why these packages have
> changed ('I user the XY-europa-fall package, now I switched to the
> XY-europa-winter package and this feature is missing')
> But with Ganymede we can adjust the package content (keeping in mind that it
> is easy to add something, but hard to remove anything... so we need to be
> very conservative)
I think saying that things can't change because it would be 'hard to
explain to users' doesn't really work for me. Why? Because new
software *is* change. If the EF (and it's associated projects) want to
have 'innovation networks', then things must change. Like a shark, if
it's not moving forward, it's dead :).
I guess I'm not so worried about users and change as you are. Change is
constant (especially in sw dev tools). I don't think that is avoidable.
Now I think it's possible to make it simpler for users to deal with
change, but I thought that's what EPP was really setup to do.
>
> * 'Community feedback' -> Maybe we need to specify this more clearly... but
> this is one reason for this discussion on the newsgroup.
>
> * 'Small' -> IMHO this is the download size (and only the download size). I
> was really surprised that the (small) Java package is on the top position
> of every download statistic.
small Java package?
Of course JDT is in the top position in every download statistic...it's
where Eclipse started out and where it achieved its popularity. I don't
think this is surprising or even informative.
RE: download size...OK. But as I said in previous note, if (download)
size is the metric of importance then why wouldn't/shouldn't this be
applied to existing EPP packages as well?
Just for reference ECF's 2 core plugins total ~110K. Further, these and
2 other ECF plugins (totalling about 400K) will be in the core Equinox
distribution for 3.4 (to support the Equinox p2 work).
>
> * 'Release train only' -> The likeliness that a project from the release
> train delivers something stable, well tested, etc. is higher than that of
> other projects. Based on that assumption it is a natural decision to use
> this as a prerequisite for building stable and reliable packages.
I agree that the release train is more likely to deliver something
stable, well-tested, etc...at least in theory.
I don't have major problems myself with this particular policy idea, but
that's because my project is already part of the release train. I think
that other projects might...probably because they don't even have the
resources to do the things necessary to participate in Ganymede...not to
mention do additional things to get included in EPP.
BTW, why doesn't EPP just become
>
> * 'Discussion' -> We are trying to get feedback... and I am sure you will
> agree that we need some policy/instructions for a project that wants to be
> part of an EPP package.
Yes, that is my major point...EPP certainly does need
policy/instructions for a project that wants to be part of an EPP
package. But those instructions will be useless/meaningless to projects
if it is not possible for them to do anything that will lead to
inclusion in EPP.
Scott
|
|
| |
| Re: Policies for EPP [message #575392 is a reply to message #6429] |
Thu, 25 October 2007 14:42 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Ian Skerrett wrote:
>> I think saying that things can't change because it would be 'hard to
>> explain to users' doesn't really work for me. Why? Because new software
>> *is* change. If the EF (and it's associated projects) want to have
>> 'innovation networks', then things must change. Like a shark, if it's not
>> moving forward, it's dead :).
>
> Scott, there is lots of change that happens in Eclipse. We are just talking
> about the packages that EPP is producing.
Of course I understand that. But if the projects don't have a
distribution mechanism, that positive change/innovation will never reach
anyone.
>> I guess I'm not so worried about users and change as you are. Change is
>> constant (especially in sw dev tools). I don't think that is avoidable.
>> Now I think it's possible to make it simpler for users to deal with
>> change, but I thought that's what EPP was really setup to do.
>
> I agree with Markus. The packages need to be consistent from one release
> to the next or we run the risk of confusing people. Change will happen but
> at a much slower pace than in other parts of the Eclipse community.
I think this is simply a poor judgment, and based upon user assumptions
that are biased away from innovation and toward 'business predictability'.
>
>
>> Yes, that is my major point...EPP certainly does need policy/instructions
>> for a project that wants to be part of an EPP package. But those
>> instructions will be useless/meaningless to projects if it is not possible
>> for them to do anything that will lead to inclusion in EPP.
>
> I actually think most projects will NOT be included in the EPP packages. I
> think this is where you and I probably disagree.
Yes.
EPP will fail if it starts
> to include too much stuff.
I think this is wrong. EPP will fail if it doesn't deliver what people
want and the projects need to survive and flourish.
They need to include the base functionality but
> encourage the use of update sites to get additional project functionality.
Encouraging update sites is fine/good, but as the Europa download
numbers show, EPP is/will be responsible for a lot of distribution...to
the detriment of the projects that cannot participate (because you say
they can't).
>
> If EPP is viewed as the primary distribution channel for Eclipse projects
> then we will fail; in my opinion.
I disagree.
I suppose this means all the second class projects will have to wait for
p2 tech to get additional distribution through EF. A shame.
Scott
|
|
|
| Re: Policies for EPP [message #575426 is a reply to message #6448] |
Thu, 25 October 2007 16:08 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Just to chime in with a neutral outsider's opinion:
I agree mostly with the policies as originally posted; specifically with
the idea that EPP packages are more carefully/slowly/strictly evolved
than the general Eclipse ecosystem. I'm coming at it as a person who
spends countless hours answering questions on the newsgroups, many of
them from newbies. From that perspective, the primary benefits I am
hoping to get from EPP are simplicity, ease, and safety. I'm still
waiting for an installer for the ease part and some of the safety part,
but the simplicity part has been taken care of by (careful, with
community feedback) selection of a small number of general-purpose
packages. I would not want to see the Downloads page polluted with a
menagerie of choices that need more than a blurb of explanation.
Perhaps a compromise would be to allow EPP to be a little more broad in
its acceptance policies, but to NOT include all available packages on
the default Downloads page.
Eric
Scott Lewis wrote:
> Ian Skerrett wrote:
>>> I think saying that things can't change because it would be 'hard to
>>> explain to users' doesn't really work for me. Why? Because new
>>> software *is* change. If the EF (and it's associated projects) want
>>> to have 'innovation networks', then things must change. Like a
>>> shark, if it's not moving forward, it's dead :).
>>
>> Scott, there is lots of change that happens in Eclipse. We are just
>> talking about the packages that EPP is producing.
>
>
> Of course I understand that. But if the projects don't have a
> distribution mechanism, that positive change/innovation will never reach
> anyone.
>
>
>>> I guess I'm not so worried about users and change as you are. Change
>>> is constant (especially in sw dev tools). I don't think that is
>>> avoidable. Now I think it's possible to make it simpler for users to
>>> deal with change, but I thought that's what EPP was really setup to do.
>>
>> I agree with Markus. The packages need to be consistent from one
>> release to the next or we run the risk of confusing people. Change
>> will happen but at a much slower pace than in other parts of the
>> Eclipse community.
>
>
> I think this is simply a poor judgment, and based upon user assumptions
> that are biased away from innovation and toward 'business predictability'.
>
>>
>>
>>> Yes, that is my major point...EPP certainly does need
>>> policy/instructions for a project that wants to be part of an EPP
>>> package. But those instructions will be useless/meaningless to
>>> projects if it is not possible for them to do anything that will lead
>>> to inclusion in EPP.
>>
>> I actually think most projects will NOT be included in the EPP
>> packages. I think this is where you and I probably disagree.
>
> Yes.
>
> EPP will fail if it starts
>> to include too much stuff.
>
>
> I think this is wrong. EPP will fail if it doesn't deliver what people
> want and the projects need to survive and flourish.
>
>
> They need to include the base functionality but
>> encourage the use of update sites to get additional project
>> functionality.
>
>
> Encouraging update sites is fine/good, but as the Europa download
> numbers show, EPP is/will be responsible for a lot of distribution...to
> the detriment of the projects that cannot participate (because you say
> they can't).
>
>>
>> If EPP is viewed as the primary distribution channel for Eclipse
>> projects then we will fail; in my opinion.
>
>
> I disagree.
>
> I suppose this means all the second class projects will have to wait for
> p2 tech to get additional distribution through EF. A shame.
>
> Scott
|
|
| | | |
| Re: Policies for EPP [message #575540 is a reply to message #6486] |
Thu, 25 October 2007 22:55 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Ian Skerrett wrote:
>> Encouraging update sites is fine/good, but as the Europa download numbers
>> show, EPP is/will be responsible for a lot of distribution...to the
>> detriment of the projects that cannot participate (because you say they
>> can't).
>
> Sorry I don't buy that EPP is the only distribution mechanism and if you are
> not included it is to the projects detriment.
I did not say that EPP was the only distribution mechanism provided by
EF. But it clearly is emphasized (and as the numbers show this is
having the intended effect).
Only necessary evidence: http://www.eclipse.org/downloads/
That is like saying if you
> are not included in the Platform project, you have no hope of success.
I didn't say this either. *Not* getting distribution through the EF
website makes it more difficult for projects to get accepted and used.
This is to their detriment.
and
> lots of projects have proven that is not true. In fact, probably the only
> project that has benefited from being included in EPP is Mylyn.
I'm not sure why you say this. Although I wouldn't doubt that Mylyn has
benefited tremendously (simply because it's the least well known/newest
of the projects included in the EPP distributions), this doesn't mean
that it's the only project that has benefited (?).
I would say more distribution (for any project) is better. Less
distribution is a detriment. I would guess that the effects either way
are larger for projects that are not as well established (i.e. newer).
And, BTW, I'm in favor of EPP allowing other packages to be constructed,
but it currently doesn't seem possible.
>
> I really think you are trying to make EPP into something that it wasn't
> intended to be.
What was it intended to be then? I *don't* expect that it is intended
to be a way for a few favored projects to get greater distribution.
But rather:
1. Create entry level downloads based on defined user profiles
What about other user profiles (like, for example, team development, or
build/deploy master)? Seems like these are in scope. If not, why?
2. Provide an installer that improves the install experience of new
users of Eclipse
'Eclipse', last time I checked, includes projects not participating in
EPP (currently). At least I believe it should (or, more accurately, it
should be possible).
3. Provide a platform that allows the creation of packages (zip/tar
downloads) from an update site.
OK, I for one would be happy to do this. Can I?
Scott
|
|
| |
| Re: Policies for EPP [message #575615 is a reply to message #6505] |
Sat, 27 October 2007 09:46 |
|
Ian Skerrett wrote:
>> Just to chime in with a neutral outsider's opinion:
>
> Thank you for doing so. I actually wish more people would express their
> opinion and you certainly are not an outsider.
>
>>
>> Perhaps a compromise would be to allow EPP to be a little more broad in
>> its acceptance policies, but to NOT include all available packages on the
>> default Downloads page.
>
> The goal is that EPP will produce a set of framework that other people can
> use to build their own packages. We then create a 'interesting packages'
> page from the download page that lists all the available packages. Those
> packages would be created and tested outside of EPP, so they would not
> follow these policies.
And in the end the download stats of those 'interesting packages' would be
another input source of what people want. That's very worthfull information
to adjust and to change the EPP package content accordingly.
But if we are going to provide such a page, we have to ensure that it
scales. How do you find the best available package, if there are a few
hundreds of them? How do we distribute this huge amount of data?
I expect that many of this kind of questions need to be solved, but it
definitely is worth the effort. Maybe in cooperation with Bjorn's plan of a
standard project download page?
Markus
--
Twitter: @mknauer23 and @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: Policies for EPP [message #575882 is a reply to message #6524] |
Fri, 02 November 2007 21:27 |
Mik Kersten
Messages: 287
Registered: July 2009 |
Senior Member |
|
|
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-co uncil/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/
|
|
|
| Re: Policies for EPP [message #575905 is a reply to message #7339] |
Wed, 07 November 2007 21:56 |
Eclipse Webmaster
Messages: 607343
Registered: July 2009 |
Senior Member |
|
|
Very insightful, thanks.
D.
Mik Kersten wrote:
> 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-co uncil/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/
--
Eclipse WebMaster - webmaster@eclipse.org
Questions? Consult the WebMaster FAQ at
http://wiki.eclipse.org/index.php/Webmaster_FAQ
View my status at http://wiki.eclipse.org/index.php/WebMaster
|
|
|
Goto Forum:
Current Time: Fri Nov 08 23:42:10 GMT 2024
Powered by FUDForum. Page generated in 0.05901 seconds |
] 
Search
Help
Register
Login
Home
