Details
-
Type:
RFC
-
Status: Withdrawn
-
Resolution: Done
-
Component/s: Document
-
Labels:None
Description
The dev guide, as currently worded, doesn't differentiate between moving/renaming whole packages/large pieces of code, and moving single files.
This proposal is to specifically amend that page to only mandate that process for moving entire packages, and allow single file moves to be done freely.
Attachments
Issue Links
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
The dev guide, as currently worded, doesn't differentiate between moving/renaming whole packages/large pieces of code, and moving single files.
This proposal is to specifically amend that page to only mandate that process for moving entire packages, and allow single file moves to be done freely. |
The dev guide, [as currently worded|https://developer.lsst.io/stack/transferring-code.html], doesn't differentiate between moving/renaming whole packages/large pieces of code, and moving single files.
This proposal is to specifically amend that page to only mandate that process for moving entire packages, and allow single file moves to be done freely. |
| Watchers | Merlin Fisher-Levine, Tim Jenness [ Merlin Fisher-Levine, Tim Jenness ] | Kian-Tat Lim, Merlin Fisher-Levine, Tim Jenness [ Kian-Tat Lim, Merlin Fisher-Levine, Tim Jenness ] |
"Freely" can encompass a lot.
Does this mean that there could be a single commit in the destination repo of copied and renamed code, rather than separate commits for copying and renaming? Presumably the branch and ticket descriptions would still at least vaguely refer to the transfer, but there would be no requirement that the source repo be mentioned? Would the same branch/ticket name still be used in both the source and destination packages, or could different branches be used? Could the code remain in the source package indefinitely?
I'm all for this. The two-branches system is a nightmare to rebase if there are any concurrent changes, and I don't think it actually accomplishes anything.
Though I do think we should still have some rules, like separate commits for moving and editing (Git/GitHub are getting better about presenting combined moves+changes coherently, but they're not all the way there yet).
Krzysztof Findeisen
added a comment - I'm all for this. The two-branches system is a nightmare to rebase if there are any concurrent changes, and I don't think it actually accomplishes anything.
Though I do think we should still have some rules, like separate commits for moving and editing (Git/GitHub are getting better about presenting combined moves+changes coherently, but they're not all the way there yet). | Remote Link | This issue links to "Page (Confluence)" [ 23802 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 23887 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 23958 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 24057 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 24212 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 24301 ] |
| Resolution | Done [ 10000 ] | |
| Status | Proposed [ 10805 ] | Withdrawn [ 10605 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 24365 ] |
Is it still the case though that the code you move would get attribution in the commit message?