tbd
Details
Details
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- arcpatch-D17020
- Lint
Lint Errors - Unit
Tests Passed - Build Status
Buildable 15405 Build 20294: Run Core Tests Build 20293: arc lint + arc unit
Event Timeline
Comment Actions
- $release->canAcceptChangeRequests()
- conduit .edit, .search methods
- db migrations
- custom fields
- add TODO and OPEN QUESTIONS
Comment Actions
@epriestley: When you have a chance, I've gathered some mostly-technical questions that I'd like your input on:
- expandTransaction: Because I decided to implement "custom actions" using transactions (P2009), I ended up having xactions that are shown on the timeline ("avive has frozen this release"), but their actual work is been handled by another xaction ("CloseBranchTransaction"). expandTransaction is how the old transaction code handled this, but it didn't make it to the modular code. Should I just find a new way to do it?
- What kind of Edges do we need? RepositoryInRelease, ObjectRequestedAsChangeForRelease, ChangeRequestInRelease, ?
- Should Change Request have their own policy, subscribers, comments, etc.?
- Transactions Metadata: That one didn't make the cut for modular-transactions either. For the case of "Updates on CR show up on the Release page", they would be very useful. Do we hate it?
- In Releeph, there's a "want" status, that's corresponds to Differential's Accept, and distinct from "Pull" status. Is that an important enough feature to include as first-class? Is there a way to include something like that (A user->value mapping) as a Custom Field?
- EditEngine::buildCustomEditFields(): Why don't we move the field definitions into the *TransactionType classes, and then use reflection to implement this method? It looks like there's a 1-1 relation between fields and xaction types.