Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Target audience of Juno repo

Just my personal opinion, but given that the Marketplace Client is quite popular and is included in almost all of the packages, I would recommend that Eclipse projects take the time to make their project distributions available via that channel.

 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: May-29-12 12:39 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

 

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

 

 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles Parker
Sent: Tuesday, May 29, 2012 9:25 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

 


+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

 

______________________________

Miles T. Parker

Senior Solutions Architect

Tasktop

Committer, Eclipse Mylyn and Virgo

Project Lead, Model Focussing Tools and AMP

skype: milestravisparker

 

 

 

 


Back to the top