Community
Participate
Working Groups
The current graduation review process http://www.eclipse.org/projects/dev_process/graduation-review.php is oriented very much towards graduating whole projects that were started from nothing and had to develop both code and a community. As we now have many incubators associated with mature projects, we are starting to see the need for graduating components and even smaller grained elements of incubators. Much of this work is being done by committers on the related mature project and the community working in the incubator is largely the same as that of the mature project. Having said that, the graduation review process is still interesting for (at least) the following reasons - wider community notification - ensure all IP issues are resolved (no outstanding parallel IP isuses) - establishing what happens to the committers working on the incubator when the code is moved We would appreciate your guidance on how best to address these in the upcoming graduation review requests for a series of things from the Eclipse Project Incubator. Note also that we may well have a number of these cases as the code in the incubator matures. Your guidance on the frequency and granularity of these reviews would also be appreciated.
We/I am happy to listen to suggestions about how we might modify the graduation review process for this situation but at the moment I'm not seeing any obvious changes. We still want to have a public review and that review still needs to cover code, community, and legal issues. I'm marking this as WORKSFORME, but feel free to reopen it with concrete suggestions that we/I can consider for the next revision of the development process. Thanks.
- remove all references to "project" and replace with "code to be graduated" or some such - detail how incremental graduations should be handled - explicitly acknowledge, facilitate and stream line the case where the incubator (source) of the code is closely related to the destination - explicitly talk about commit rights and what happens to them for the various parties (source and destingation committers)
One question in this area is at what granularity of code being graduated is a review warranted? Say I am a committer on both an incubator and mature project. I checkin a single class authored entirely by myself into the incubator, and then decide this same class is needed in the mature project. Presumably there is nothing wrong with me (the sole code author) directly recontributing that same code into the mature project as long as I follow the usual committer guidelines with respect to IP, etc. Repeat the same question with a single Java package, or an entire bundle. At what size, or what other characteristics of the code being graduated, is a graduation/move review warranted? Clarification of these issues in the development process would be appreciated.
I claim that the proposed new version of the Eclipse Development Process (just posted, see http://eclipse-projects.blogspot.com/2008/03/edp-2008-1-hierarchical-projects.html) fixes these problem. I am going to mark this bug as RESOLVED/FIXED even though: (1) the proposed new version has not yet been adopted by the Board, and (2) I have not yet revised the guidelines (such as the url in the description of this bug) - I will revise the guidelines after the Board adopts the core EDP because the guidelines are based on the core EDP. Please direct comments about the proposed revised EDP to bug 220871 so that we have a single place for the conversation.
(In reply to comment #3) As long as the code was written by you and not a "major contribution", then there is nothing against 'writing' it for two projects. But once the code becomes a major contribution, then a move review becomes necessary.
