Hello, On Mon, Oct 23, 2017 at 12:43 PM, Ed Willink <[email protected]> wrote:
> Is it intended that we move to no sources in SimRel in which case projects > providing sources are at fault? Or should we consistently provide sources, > in which case the projects that neglected to double up in their *.aggrcon > are at fault. If we want sources, the "XXX", "XXX Developer Resources" > visual clutter could usefully be absorbed by a checkbox or two? I don't think there is a rule enforced on this topic and it seems to be usually a project decision about whether to contribute the sources/developer resources to SimRel according to project specificity. For example, if a project is plain end-user oriented (like EGit), then in the vast majority of cases, sources wouldn't be useful for most users, and it seems better to not crowd SimRel with those. Plugin developers always have the opportunity and the skills to get those sources from the EGit repo directly rather than SimRel. If you consider project dealing with generation of plugin code (like EMF), then it can make sense to have 2 distinct features: one for end-users, purely to package EMF runtime dependencies, and another for EMF plugin developers, who would most likely want all the documentation and sources to be more productive with EMF in their work. And finally, if you consider plugins which are purely about Plugin Development (PDE, GMF Tooling), then it may be better to simply ship the "Developer Resources" feature in SimRel, as the Sources and Documentation are part of the value of the project for most users. Those examples seem to show that there isn't one approach that's definitely better than another and that it all depends on how the project is used. It seems better to leave the responsibility for a project to include what is best for most of its users (but to remind project to not push a lot of extra stuff if the value is not guaranteed). My 2c, Mickael
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
