Bug 418432 - change in "automatic disablement" procedure for next year's Sim. Release (Luna +1)
Summary: change in "automatic disablement" procedure for next year's Sim. Release (Lun...
Status: RESOLVED FIXED
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Cross-Project (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P1 normal (vote)
Target Milestone: ---   Edit
Assignee: David Williams CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-01 11:28 EDT by David Williams CLA
Modified: 2015-10-01 20:23 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2013-10-01 11:28:22 EDT
One awkward aspect of our procedure has been how to get "affirmative" joining of release train, and coordinating that with contribution files. For past few years, this has been done by copying previous year's files, but disabling contributions and requiring projects to consciously "join" be enabling their contribution. 

But this is disruptive, since often for first milestone or two, people are merely contributing their "previous release", but if it is disabled, then others "above" them in the chain are broken until the "lower" projects re-enable their contribution. 

With the change in procedure of "announcing" participation, as announced on cross-project list, and described in 
http://waynebeaton.wordpress.com/2013/09/09/eclipse-luna-whos-in/

and with the Foundations databases updated based on that announcement to seed the "participating" list at sites like
https://projects.eclipse.org/releases/luna

it will be possible to leave everyone "enabled", at the beginning of a new year. 

But, there will be a point when a project has not "announced" ... either because they'd forgotten, or because they really are not going to participate any longer ...  but they will still have a file in org.eclipse.simrel.build. And, with historical examples, sometimes they will continue to "build" without anyone ever noticing. 

So, we still need a "disable" and eventual "remove" procedure. And that's what this bug is about. 

I propose that if a project (that was previously participating) has not announced by the end of M2, that they be disabled right after M2. That should "shake out" anyone who's merely forgotten, so if by the end of M3 (right after M3 comes out) the contribution will be removed. Since "brand new" projects have until M4 to join, this means by M4 we should have a completely accurate "picture" who's in and who's not. 

To cross-reference, this bug is related to bug 298259. 

See also bug 416861 for an alternative view and comment there if desired. 
(But, remember, we want to meet all the objectives outlined in 
http://waynebeaton.wordpress.com/2013/09/09/eclipse-luna-whos-in/ )

I wanted to open this bug to give projects a chance to comment before this goes into effect next year. If there's no alternatives that come up, in next month or two, I'll document this on wiki and count this as resolved.
Comment 1 Eclipse Genie CLA 2015-09-22 11:42:27 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 2 David Williams CLA 2015-10-01 20:23:20 EDT
This can be counted as "fixed" ... a long time ago ... since we did change the procedure.