[Bug 368193] [EDP] Code moves are too hard

Bugzilla Link	368193
Status	NEW
Importance	P3 normal
Reported	Jan 09, 2012 15:03 EDT
Modified	Oct 25, 2021 12:00 EDT

Description

To move code from one eclipse project to another currently requires a Restructuring Review. The EDP defines Restructuring Reviews as relatively flexible things that can be used to refactor a project or projects, change scope, move code, etc.

To just move some code from one project requires:

1. Creation of review documentation;\
2. IP Log approval for the source project; and\
3. One week of community review.

The review is then followed by the actual process of moving code, committers, CQs, Bugzilla records, etc. with assistance from EMO staff.

For restructuring reviews in general, I have been accepting very concise documentation (very often delivered as Bugzilla comments) that describe the change. As far as reviews go, I think this is pretty lightweight. Can we do better?

Backing up a bit, it's probably a good idea to revisit why we do these reviews at all. The main idea is to make sure that the community gets a chance to understand what's happening and react/respond to the change. With that in mind, I find myself questioning if a week-long review period is enough?

I tend to fall back on the idea that if the community cares about the change, then they've probably been listening all along and should know about it. If the involved projects haven't been talking about the change publicly and end up surprising their community with the change, then we have a different sort of problem.

This then brings me back... if the projects have been keeping their respective communities in the loop, then why do we need to spend a week at all?

Maybe it's enough to replace the notion of a review with an announcement that contains a description of the change and discussion of how the community has been involved with the process? A move review could be as simple as stating that some chunk of code needs to be moved from one project to another, combined with a pointer to the mailing list entry that started the conversation about the move.

To summarize:

1. Create documentation that describes the change;\
2. Post it on the communication channels used by the projects;\
3. Address concerns raised in those communication channels;\
4. When the discussion wraps up, bring the change to the attention of the respective PMCs for their approval; and\
5. Tell the EMO what you did.

We leave it to the PMCs to decide in step 4 if further discussion is required before granting approval.

Thoughts?