| Re: [epp-dev] Re: [eclipse.org-committers] Eclipse project announcement |
|
See embedded comments Timothy Webb wrote: There is no need for this to have any more impact on projects than the current EPP design and delivery strategy does. EPP consumes the bits that the projects output and makes them available to people. Things may evolve over time to get more and more sophisticated but my hope is that we keep it simple at least to start. If stuff is in a repo somewhere that EPP knows about then it *can* be part of this. Since everyone is already putting stuff in repos, there is nothing to do. Please to not mischaracterize what we are talking about here. No one has ever suggested "experimenting with changes live on the Eclipse.org server." Of course the infrastructure would live somewhere on an eclipse.org server but that happens all the time. Making it in the mainstream of the downloads site would be something that would be carefully considered and reviewed like anything else. Tim, please be assured that there is no lack of visibility but rather more a lack of something to see. There is a prototype yes. It is supposed to be in the EPP CVS. I thought it was there but perhaps it has not made it yet. AFAIK there has been no work on the prototype and literally been no communication (open or otherwise) other than the bits we see here since the decision to not push on this for Ganymede. It is not at all that interest has diminished but rather that things get prioritized. As for motivations, they were captured quite simply IMHO in my original email about this http://dev.eclipse.org/mhonarc/lists/epp-dev/msg00221.html The key is to think SIMPLE. To summarize, there are two things motivating this work. 1) there is lots of stuff at Eclipse that is hard to find/get 2) eclipse.org is not a showcase for its own technology. For 1, I believe that most of the Eclipse consumer world can easily associate themselves with some small number of consumer roles. Java Developer, Report author, ... But there are many things at Eclipse that are applicable to them that they don't know about. Simple solution is to offer these base packages (ala what EPP does today) and based on these packages guide them to customizations/additions that are applicable to them. There is actually a 1a) recognizing that there is lots of stuff in the Eclipse ecosystem that is hard to find. That is where the discussion of the "referrer URL" (for lack of a better term) idea came in. Basically the ability for one server/site to pass off the list of things (perhaps shopping cart?) current selected to another server/site. There is no expectation or requirement in that that says the various servers/sites need to be running the same software. Ultimately the user arrives at a list of things to install and they can then easily get that stuff. Simple. For 2, with the agreed upon strategy in the Eclipse Foundation to push Eclipse as a runtime technology it only makes sense to look at ways of exploiting and showcasing Eclipse project technology at eclipse.org. We have a number of very cool and very significant technologies to apply here. Equinox, ECF, p2, RAP and perhaps others. The case where someone is discovering some Eclipse function on the web and wanting to try it out is great. To me that breaks down into two subcases. 3a) they already have Eclipse and find some new stuff they want to add and 3b) the user has nothing Eclipse but wants to try something. For the former, I believe that this is best approached through p2 facilities that, for example, allow users to drag and drop URLs on their Eclipse to install stuff. This has been discussed in the p2 community for a long time now. For 3b) in the current model this would amount to having the web link be a referred URL (again, don't take that literally) that kicks off the wizard (whatever) seeded with the stuff the user just found. I have digressed somewhat into a design discussion but my real point is that we don't have to boil the ocean to start working on something and see how it goes. As mentioned above, the direction/approach being contemplated here is no different from what happens in many Eclipse and other open source projects today. People interested in a particular problem gather around the seed of an idea (see previously cited email) to create designs and implementations and then iterate. Though this process there is much discovery of requirements, approaches, technologies, solutions etc. This process continues until such time as the state is deemed "release worthy". At that time the code/function is put into action in a wider context and the team continues iterating and refining and releasing. This is XP, agile, simple and has been used with proven success in many Eclipse projects. See the various presentations on "The Eclipse Way" at EclipseCon and ESE. I don't think the waterfall approach that you propose makes sense here. Having said that, perhaps we just disagree on software engineering methodologies. Tim, you did not comment on this part of Jochen's message. I asked a similar question in another message. Can you clarify the ways in which you feel limited? My concern is that we have a mismatch in what we are talking about. Jeff |