Community
Participate
Working Groups
At the STAC meeting at EclipseCon this year, we talked about the need for better testing of the Galileo packages before they are released. This would be greatly improved if the Galileo packages were easier to find from the main eclipse.org download page *before* the final release date. Today I wanted to download Galileo M6, but couldn't find it on the download page. I eventually found via google an email from Markus that contained a link to the page: http://www.eclipse.org/downloads/packages/release/galileo/m6 After more investigation I found that there is a link in the far bottom right corner of the main download page that says "More Eclipse Packages", and from that page I found a link to the Galileo packages. I think it would greatly improve our community pre-release testing effort if the pre-release EPP packages were easier to find.
How about adding a new tab to the main downloads page that links to the latest milestone packages? The label of such a tab would would have to be "right" but I think that would add the needed visibility of these pre-release builds. Some ideas for a tab label: "Pre-release Builds" "Development Builds" "Milestone Builds" "Early Adopters" "Upcoming Release"
And I wanted to add that in general it is difficult to find these basic non-release platform builds. So I think this goes beyond Galileo and should be generalized for future releases. (see also bug 205205) IMO, users should be able to easily find a page similar to this: http://download.eclipse.org/eclipse/downloads/ There are a couple of areas of confusion here -- why should the user have to know that they need the "classic" build when all they care about is having a binary build (that they can then customize)? Why would I know that "Other Downloads" meant "more recent builds"? I realize that there are a lot of dimensions that are being tracked here and its hard to reconcile them but I think there needs to be some way to make the more leading edge releases more accessible, especially as they are so high-quality. ;) A single hot-link along the lines of "Older Versions" would make things a lot easier and as John mentions enlarge the testing community.
I've added a new tab to the downloads page called "Development Builds" This tab will show the latest milestone builds from the EPP project, and is an extension of the Packaging Site.
I like the way it looks. Easy to find (and describe to someone) but not intrusive.
+1, this looks great. Thanks for doing this Nathan. One small addition I would suggest is adding a link to bugzilla. The motivation for making pre-release builds more visible is to encourage community testing and participation. I would change this: The packages below are pre-release milestones of the upcoming Galileo Release Train. If you are looking for the latest release please visit the Eclipse Packages tab. To something like this: The packages below are pre-release milestones of the upcoming Galileo Release Train. If you are looking for the latest release please visit the Eclipse Packages tab. If you encounter problems with these builds, please report them <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPP">here</a>.
Great suggestion John. Even better that you provided the <a href="... for me!! Committed.
Great! Makes it much easier for me to get clean builds for people who are using my 3.5 dependent tools. Now, I feel almost ungrateful mentioning this, but the path to get to the *interim* and other builds at I think the language for the link is a little unclear.. "Note: There might be a newer release candidate available. Please look at the Eclipse Project download page." to something like "Integration and other more recent builds can be found on the Eclipse Project download page." http://download.eclipse.org/eclipse/downloads/ is still a little unclear. And I guess that this appears under the "classic" build as that is the actual build that the interims are targeting. But this is not going to necessarily be clear to someone who has been asked to get the "Eclipse I20090603" build. Perhaps its the "classic" name that throws me and if it happened to be called "eclipse core platform" or something it wouldn't. Not to mention the fact that it appears on the bottom of the page! :) So for the never satisfied, what about moving that note to the top notes so that it would read something like: "The packages below are pre-release milestones of the upcoming Galileo Release Train. If you are looking for the latest release please visit the Eclipse Packages tab. *If you want to explore the bleeding edge of Eclipse, you can find the latest integration and nightly builds here.* If you encounter problems with these builds, please report them here." One tiny nit, I'm not sure that its clear that the bug category is for the builds themselves, not bugs within the built products.
(In reply to comment #7) > I think the language for the link is a little unclear.. "Note: There might be a > newer release candidate available. Please look at the Eclipse Project download > page." to something like "Integration and other more recent builds can be found > on the Eclipse Project download page." > http://download.eclipse.org/eclipse/downloads/ is still a little unclear. In my opinion changing that sentence to what you suggested makes it more unclear. I would suggest that most people have no idea what an integration build is. > And I guess that this appears under the "classic" build as that is the actual > build that the interims are targeting. But this is not going to necessarily be > clear to someone who has been asked to get the "Eclipse I20090603" build. Again, if someone is asking you to get "Eclipse I20090603" build then they should either have some idea of what they're looking for and how to get it, or you should provide them a link. > Perhaps its the "classic" name that throws me and if it happened to be called > "eclipse core platform" or something it wouldn't. Not to mention the fact that > it appears on the bottom of the page! :) We've visited this discussion before, to be clear, the Classic download is staying put (at the bottom). We're making a conscious effort to promote the packages (as both the main download page, and development builds) as they provide more user benefit. > One tiny nit, I'm not sure that its clear that the bug category is for the > builds themselves, not bugs within the built products. I'm open to suggestions on changing this to be a bit more clear, but the download numbers don't lie. For the Ganymede SR2 packages we have 1,719,586 downloads of the packages, and 482,420 downloads of the Classic SDK. That's a 4:1 ratio. IMO getting these packages tested is just as important as the SDK.
I agree we shouldn't promote the eclipse TLP downloads page over the EPP packages and other projects. From my point of view this can be marked fixed.
I think Miles' primary point about the "Classic" download was that the name is confusing/arcane. Can we leave it where it is but rename it to "Eclipse Core Platform" or something more clear?
(In reply to comment #10) > I think Miles' primary point about the "Classic" download was that the name is > confusing/arcane. Can we leave it where it is but rename it to "Eclipse Core > Platform" or something more clear? > Please open a new bug for this discussion. Closing out this bug as FIXED.
NP. Eric is right, its the name that is the source of confusion. I don't have any argument with the fact that most users are going to better served by a more full featured build. I'll consider posting a bug for it. I agree that this is fixed. But my issue remains and so at the risk I'm being a PITA I don't want to waste everyone's time opening yet another bug for integration builds. If my issue is idiosyncratic I'll drop it. But given: 1. There ought to be *some* path to every useful resource from the eclipse.org home page. 2. Integration and nightly builds are an important resource for a significant number of Eclipse users. 3. Use of these builds helps Eclipse committers by giving early feedback for new fixes and features that by definition should not show up for the first time in M builds. 4. The top-most level "Downloads" tab is the most obvious place for anyone to look for a download of those builds. Isn't it reasonable to ask that there be some way to reach this build page in some transparent way from the downloads page? > Again, if someone is asking you to get "Eclipse I20090603" build then they > should either have some idea of what they're looking for and how to get it, or > you should provide them a link. OK, how about "you should try one of the later integration builds"? Providing a random disconnected link is one way to do it. Giving the instructions "Click on the downloads tab. Find Eclipse Classic 3.5.0 M6 [This will change of course]. Click on Other Downloads." is another. Even though *I* know what I'm looking for, I have a hard time finding the page if I'm on a different machine and I don't have the URL handy.
> at the risk I'm being a PITA You are not. Discussion is always healthy, > But given: > > 1. There ought to be *some* path to every useful resource from the eclipse.org > home page. The problem is that 'useful' varies wildly from one person to the next. You think Integration builds are useful. Many think otherwise, so we need to balance. > 2. Integration and nightly builds are an important resource for a significant > number of Eclipse users. Actually, the bleeding-edge crowd is a very small percentage of the intended audience of the Main Downloads page. Furthermore, there are other places you can go for this stuff: ==> http://www.eclipse.org/users/ This is in the top nav on every page. Has links to *everything* including Report Bugs, Source Code, Nightly Builds ==> http://www.eclipse.org/committers/ This is also in the top nav. Again, a bunch of resources for our beloved committers -- but not just limited to them! > 3. Use of these builds helps Eclipse committers by giving early feedback for Agreed. But not everyone can, or wants to, run an I-build. > Isn't it reasonable to ask that there be some way to reach this build page in > some transparent way from the downloads page? It's a reasonable request, really. But just sit back and look at that Downloads page for a moment. It is crowded. It is too crowded. We need to pick and choose what goes on there. Unfortunately (for you, but fortunately for millions of other users), links to I-builds are elsewhere. So, the question I'm asking you, is: Knowing there is a Nightly Downloads link on the Users page, and probably other links that you may find useful, what can we do to make that page appeal to you?
Thanks Denis. (In reply to comment #13) > > 2. Integration and nightly builds are an important resource for a significant > > number of Eclipse users. > > Actually, the bleeding-edge crowd is a very small percentage of the intended > audience of the Main Downloads page. Yes, I buy that. Vanishingly small. > It's a reasonable request, really. But just sit back and look at that > Downloads page for a moment. It is crowded. It is too crowded. We need to > Knowing there is a Nightly Downloads link on the Users page, and probably other > links that you may find useful, what can we do to make that page appeal to you? Interesting. Information design is hard as I discovered while putting together my own CMS based front end. There are so many over-lapping dimensions. And I've used the Eclipse site for so long that I never really explored the changes. I see two areas for improvement though but I don't make a good case as a first time visitor: 1. The top-level path isn't obvious. I think some cognitive dissonance comes from the fact that some of the top-level choices are role-based and some are task-based. I tend to approach my interaction from a task based perspective and if I see "downloads" on the top-tab, that's where I'm going to head, that is if I don't see a role-category that fits me very closely. I'm sure the web team has explored all of this ad naseum. User implies end-user to me. I hate to say it but I don't think I ever did more than glance at the "Users" page, and (until now that is!) I wasn't a "Committer" I didn't really explore that tab either. The committer category has a lot of useful resources for people who develop for Eclipse but are not Eclipse committers. And the User category has a lot of stuff like nightly builds that I wouldn't really associate with end-users. So I think there is a large middle ground between User and Committer that isn't clear. The fact that Members is placed in between makes the overlap between these roles even less apparent. And I see now that there are roles listed followed by tasks or domains (downalods, resources, projects) but it isn't obvious. Is there any possibility of refining the top-level categories? If Committer was called "Developer" that might really help, but there is all of the inside baseball stuff and anyway that would be confusing for people who are using Eclipse *for* Development. Once landed on the the pages I really liked the User (especially) and Committer approach and the way it maps to the Eclipse welcome screen. There isn't the "wall of text" phenomenon that I think makes the downloads area feel so overwhelming. (I'd suggest doing something like that for Downloads, but I'm guessing that one has also been hashed out already.) 2. Users should include link to Integration builds. I really think that these are the builds that would be most useful to those folks who want to get the very latest changes. Nightly builds are often just too flakey to be useful to anyone who isn't tracking a very specific bug. 3. Again, Committers includes a bunch of stuff relevant to Eclipse Plugin / RCP developers in general. Eclipse Wiki, What's New, separate Bugzilla icon, parts of Eclipse Development process and of course Development Builds. But then a lot of this stuff is also offered under projects.
(In reply to comment #11) > (In reply to comment #10) > > I think Miles' primary point about the "Classic" download was that the name is > > confusing/arcane. Can we leave it where it is but rename it to "Eclipse Core > > Platform" or something more clear? > > > > Please open a new bug for this discussion. Closing out this bug as FIXED. > Done. bug 273930
