| [eclipse.org-planning-council] Re: [cross-project-issues-dev] Heresy mark II (summaries and replies) |
|
To me there are several reasons to the success of the distros over our update site. (I will just name two that I find relevant to this discussion, but obviously there are many others)
Ganymede people, Some history (as I see it):
2. Originally (pre-Callisto) our goal was to have a single update site that merely *referenced* the existing project update sites. No file copying, no archiving, no building - just references so that our testers could point their update manager at a single update site url. 3. Using references in the update site did not work for technical reasons (the update manager couldn't handle it) so we went with a cobbled together single update site that copies the relevant files from the existing project's update sites. 4. This single update site has caused a number of problems including the user facing problem of having two updates site for each project: the central one and the project one. Which one does he or she get updates from? ... And there are all those update manager-related bugs where the setup hasn't worked for the simultaneous release for one reason or another (can't find required features, incorrect packing, etc.) 5. End users found/find the whole list of technical features on the central update site confusing - they've said so in bugs and blogs. Thus we started a "packages" program to provide simplified end user distros. The packages have been a pretty solid success (they account for over half of all downloads). 6. Serious adopters (companies building products on top of Eclipse projects) use the project distros or even the project sources rather than the central update site - or so I understand.
2. Packages are a better user solution 3. The central update site is work to maintain 4. Adopters don't use the central update site
2. Some statements that the effort in building the update site is beneficial - although I don't see it, so I'd really like whoever said that to elaborate on why taking existing update sites and copying the files to a single update site provides any benefit. The reported benefits (finds conflicts) should be happening by the individual project build scripts, yes? And just copying the files to the same place doesn't do any cross project testing, which would be the key advantage anyway. 3. Some statements that users want to have a single place to find all the projects and that users won't go to the project specific pages - this is perhaps the best argument, but I counter it early by pointing out that the update site wasn't a good end user experience and that systems like Yoxos or Cloudsmith were a far better end user experience and so why don't we just use something like that? Especially when someone writes "start with package X and mix in feature Y" - those other tools do it so much better than our central update site. 4. Some statements that the sheer act of building a common update site is what forces us to work together - an interesting argument, although I'd rather see a situation where we driven by value to our consumers (adopters and end users) rather than by the act of copying files to a central location. The Ganymatic does not run any tests, nor does it attempt to load all the plug-ins into memory at the same time, nor any of the things that verify that things work together. It just copies files. 5. One statement that, in effect, said that we need a common build system for Eclipse projects so that we run a consistent set of tools (indexers, etc) on the binaries.
-- [end of message] _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev |
