Bugzilla – Full Text Bug Listing
| Summary: | [EDP] Code moves are too hard | ||
|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> |
| Component: | Architecture Council | Assignee: | eclipse.org-architecture-council |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, Ed.Merks, john.arthorne, pwebster, stepper |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
|
Description
Wayne Beaton
My view is that a "move review" is not all that hard, and a week's wait is not that onerous. BUT, I do really like the idea of leaving more up to the PMCs. Perhaps it could be stated by leaving out the "1 week review" requirement, and add something to "PMCs Approve", similar to "bring the change to the attention of the respective PMCs for their approval (as part of their approval, the PMCs should state how long the community review period was; at least one week a typical, but may be longer or shorter depending on the projects, the code that is moving, and the PMCs judgment)". [You know how I like things wordy :) ] I tend to agree that a code move shouldn't need a big process. The obvious key element is that the project committers and leadership at the destination project agree to it (since it involves potentially adding commit rights for the committers associated with the code). There often isn't much community impact involved. To think of it another way, if I move code from one directory in my repository to another, no review is needed. Moving to another repository is not a much bigger step modulo commit right changes. Another point to consider is whether there is a process distinction between copy and move. If I want to copy code from one Eclipse project to another, what process is required outside of ensuring the project IP log is correct in the destination project? Does this fall under move review or something else? If copying code doesn't require a review, then it seems move can be reduced to: - copy code from project A to B (update IP log, no review) - hold committer election in project B for any new committers associated with the code - committers of project A eventually delete the copied code from project A if they have no need to reproduce old builds (no review needed) The EDP 2011 discusses the notion of requiring a Restructuring Review for the movement of "significant chunks of code". -- A Restructuring Review may include the movement of significant chunks of code. A move is considered significant if it has an impact on the community (i.e. if segments of the community will notice that the code has moved). This may include entire projects, bundles, and features, but likely excludes small fragments, code snippets and individual files. The IP Log of all moved code must be reviewed prior to the start of the review period (this, typically, is a subset of the project's IP Log). If all of the code is moved out of a project, a Termination Review for that project can be combined with the Restructuring Review. -- I believe that this provides an escape clause for "insignificant chunks of code", or functionality that has low impact on the community. Perhaps we might consider: * Changing "chunks of code" to "functionality"; * Making it explicit that the PMC should be included in the decision of whether or not functionality is "signficant" (In reply to comment #2) > Another point to consider is whether there is a process distinction between > copy and move. I think that there is. Copying doesn't disrupt consumers of the source project. I think that copying code between projects falls into the category of adding code to a project and is more of an IP Due Diligence issue than an EDP issue. > If I want to copy code from one Eclipse project to another, > what process is required outside of ensuring the project IP log is correct > in the destination project? That's how I read the IP Due Diligence poster. > Does this fall under move review or something > else? If copying code doesn't require a review, then it seems move can be > reduced to: > > - copy code from project A to B (update IP log, no review) FWIW, as long as the "Author" field is set correctly on the commit record, you're good-to-go on the IP Log. > - hold committer election in project B for any new committers associated > with the code > - committers of project A eventually delete the copied code from project A > if they have no need to reproduce old builds (no review needed) We require a review for the move because it may have an impact on consumers. It seems to me that deleting code from a project would have an at least similar impact on consumers. Maybe "deleting/archiving significant functionality" should be listed as a potential reason to hold a Restructuring Review. i.e. "A Restructuring Review may include the movement or deletion/archival of significant functionality." (In reply to comment #3) > [...] A move is considered significant if it has an impact on the community > (i.e. if segments of the community will notice that the code has moved). To what extend is the possible impact of a code move between projects different from the impact of independent code changes in both projects that lead to the same effect? I mean, if a project takes versioning seriously it already must increase the minor version for API additions and teh major version for API removal. A release with review is required already in both cases. So where's the value in mentioning code moves explicitely? (In reply to comment #6) > I mean, if a project takes versioning seriously it already must increase the > minor version for API additions and teh major version for API removal. A > release with review is required already in both cases. So where's the value > in mentioning code moves explicitely? If you move a plugin from one source repository to another, it does not necessarily impact any of the source code in that plugin. So I don't think this is related to versioning. The main impact of a move is that it changes who has commit rights to that source code. This is my ideal version of a low process move review: - The move is announced on the project mailing list for both the source and destination project. The committers on the source and destination project vote on that change. If successful, the project lead of destination project opens a bug against EMO, with a pointer to those two vote threads, and the EMO implements the rest of the move. (In reply to comment #7) > - The move is announced on the project mailing list for both the source and > destination project. The committers on the source and destination project > vote on that change. If successful, the project lead of destination project > opens a bug against EMO, with a pointer to those two vote threads, and the > EMO implements the rest of the move. Why does EMO need to be involved? If anything, you may need to request Webmaster help; that's a different thing. Should the PMC(s) be involved? (In reply to comment #7) > If you move a plugin from one source repository to another, Implying that the "other" one also belongs to another project? > it does not > necessarily impact any of the source code in that plugin. So I don't think > this is related to versioning. I believe that this is because features are considered at most second class components. I prefer to consider them kind of API because they define what's available or not. I think the consumable output of a project is ultimately induced by a set of root features. All additions of sub features or plugins should lead to an increased minor feature version. All removals of sub features or plugins should lead to an increased major feature version. With these rules moves, like any other content changes, are adequately reflected in the feature/project versions and lead to release reviews. BTW. of course it's very hard to maintain feature versions because of their transitive content relationships. That's why Ed Merks and I have developed a special Version Management Tool that automates this completely in a similar way as API Tools do it for Java APIs. > The main impact of a move is that it changes > who has commit rights to that source code. This is my ideal version of a low > process move review: > > - The move is announced on the project mailing list for both the source and > destination project. The committers on the source and destination project > vote on that change. If successful, the project lead of destination project > opens a bug against EMO, with a pointer to those two vote threads, and the > EMO implements the rest of the move. I still think that a special review should not be needed. I agree that the change of commit rights to the "old" code should be documented, but the release review of the project that formerly owned that code must list removed code/functionality anyway. Why not just require/encourage to document where it has gone, in case it hasn't been just deleted? Defering. 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. 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. 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. This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/145. |