Trying
to fragment the repository around user profiles isn’t
going to be easy or clean. Many users and use cases will
not easily fit into neat profiles.
On
the other hand, we already have a venue for presenting
users with an easier to use course-granularity
installation option… Eclipse Marketplace.
-
Konstantin
+1, but probably way too late to be asking people to make
these kind of changes now. Something that people should be
thinking hard about for Kepler. There is a major need for a
higher level of granularity on the features. Ideally it
would be one per project but that isn't practical in many
cases.
On 2012-05-29, at 8:29 AM, Pascal Rapicault wrote:
Once in a while I go through the content
of the Juno repo to see what's there; and I try to see if I
can make any sense of what is made available. Unfortunately
this year it reached a point where I just can't. There are
way too many entries that are subtle variations around the
same project and whose installation result in unexpected
results or non functional additions to my install. For
example there is 11 entries for Sapphire, 5 entries for
windowBuilder, an infinity of Mylyn related entries...?
I understand that we are all trying to
promote our project and brand, but I would argue that the
plethora of entries has a reverse effect that let the user
confused as to what to install.
So the main question is "what is the
primary target audience of the Juno repo?"
- an eclipse user - e.g. a JEE programmer
- an eclipse extender - e.g. someone using eclipse
technologies to build an app
At this point, the content of the repo
looks like what we are addressing both audience which may
be a convenience for us but a nuisance for the end users.
IMO, the Juno repo should be "end user"
focused and only include entries whose installation will
result in new functionalities to be added to the IDE. Also
each entry should have
- a descriptive name (which include removing
adjectives such as incubation, extender)
- a minimal number of entries returned when I
search for the name
- be adequately categorized
How do we go about exposing the rest of
the content for extenders?
- Different repo URLs (e.g. download.eclipse.org/releases/juno/developer)
- Addition of a developer focused category (with
nested categories)
wdyt?
Pascal
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
______________________________
Senior
Solutions Architect
Committer, Eclipse
Mylyn and Virgo
Project
Lead, Model Focussing Tools and AMP
