Community
Participate
Working Groups
In keeping with the spirit of most open source projects, it should be mandated (perhaps for the next release following Europa) that all projects hosted at Eclipse.org must have source builds. If you look at Apache or SourceForge you will see that most, if not all, of the projects hosted on these popular ope source project sites provide source builds. Providing source builds for all projects makes sense for at least a couple of reasons: i) I shouldn't be tied to CVS to be able to get the source in a workspace and modify it. I realize I can import the projects using PDE to attach the source, but this is not a foolproof way of getting the source, especially if the plug-in's source is not setup properly. ii)IP review As a starting point, the platform provides a releng tool that can load source from the repository using .map files (which I believe alot of projects use as part of their build processes). I am thinking it wouldn't be an overwhelming amount of work for each of the projects (at least those that use map files to build) to incorporate this tool into their build processes. Link to Releng tool (for 3.3 M6): http://fullmoon.torolab.ibm.com/downloads/drops/S-3.3M6-200703231616/download.php?dropFile=org.eclipse.releng.tools-3.3M6.zip Also, the platform already provides source builds. Perhaps they can provide advice for other projects on how they can generate a source build as part of the regular build process. Link to platform source build: http://fullmoon.torolab.ibm.com/downloads/drops/S-3.3M6-200703231616/sourceBuilds.php
I've moved this to cross-project, i.e. release train. I don't recall whether or not the planning council decided to make this a requirement or not, but it feels like a better release train requirement than a part of the EDP. If you disagree, please feel free to assign it back to Community/Process. Frankly, I'd like to avoid adding too many additional requirements in the EDP. I feel that this is certainly good advice for a project that wants broad adoption. Perhaps this a best practice for the Architecture Council to consider?
Perhaps there is new interest in this, related to efforts of "long term support" ? - Being able to get all the sources easily in a way that I can also build them, is a simple way of ensuring that I'll also be able to build them for fixing a bug in 10 years.
Although my projects do have individual sources for all bundles I'm against new must-dos. Where will this end?
This was on my list to close as "won't fix" soon, until all this recent discussion. Not to worry Eike, at most this would be a "should do to be good citizen" type of recommended practice, I don't see it ever reaching a "must do" level. And, to clarify, what's being asked for is a little more than "source bundles" ... but instead "source builds" ... and, as I know first hand what Karice was asking for (4 years ago :) ... its not literally a "source build" like we programmers think of source builds, but more a collection of all the source that would go into a build. We already have a "should-do to be a good citizen" item that says to document how someone else could build your code on their own system. (With widely varying degrees of compliance and success). It says ... <quote> Builds. Projects must have a mature, stable build process: documented, scripted, repeatable, and executable by others. </quote> So ... I suggest we simply add a sentence: "Ideally this includes the ability or written directions to collect all the source used to build a release, to use for other purposes, such as IP scans and the like". Is there anything more anyone wants to suggest?
(In reply to comment #4) > So ... I suggest we simply add a sentence: "Ideally this includes the ability > or written directions to collect all the source used to build a release, to use > for other purposes, such as IP scans and the like". > > Is there anything more anyone wants to suggest? We don't depend on long-term support in my company, so others may comment with more background ... but given the soon-to-come migration of many projects to a different CM system, I'd assume that many of these "instructions how to obtain source for the particular tag/release X" might get outdated soon. In my understanding, this request is more about delivering a snapshot of source that went into a release as a downloadable archive. Perhaps a snapshot of a buildable workspace would do? (just guessing).
While not officially approved yet, I've added a "requirement" to the Simultaneous Release requirements to cover this request, and count it as "fixed". It turned out to be pretty wordy ... so, might profit from future editing ... but in essence, will be similar to the following: = = = = [Added 10/18/2011] Also, projects should provide a "source build" or at least some instructions on how to get all the literal source that goes into a build. This is different than producing "source jars" during the build. The "source jars" are simply Java code that can be used in the IDE, such as for JavaDoc or debugging, but a "source build" might include additional source required to build the code, such as various property files, perhaps model or grammar specifications that are converted to Java during the build, etc. The "source build" can be though of as what it would take to build the project if someone wanted to build it "from scratch", (not from the source code repository) and also what an adopter might want to look at to investigate detailed IP issues. You can provide the literal "source" that could be used for a source build, but most projects would simply provide instructions on "how to fetch" all the source that went into a particular build. See bug 185146 for the origin of this "source build" request. = = = =
I think best to close this as "won't fix". At Planning Council review, there was some concern that this was either redundant with things we already said (e.g. document how to do a build) or that there wasn't enough specificity about exactly what was needed ... which would not be easy to summarize, to technical, programmers. Hence, if adopters need this, first work with the individual projects you need it from (open bugs, ask "how to get" questions, etc.) ... and if/when there ever becomes more of a "universal process" then we could re-consider making it a Sim. Release requirement. But, in theory, if projects have their builds well specified and documented, anyone could then get the source used in a build without depending on a project to supply it ... and having well specified and documented builds would be the preferred solution since that solves several problems. Thanks for opening the request, thanks for all the discussion points.
