Page MenuHomePhabricator

Release: start adding changerequests
Changes PlannedPublic

Authored by avivey on Dec 9 2016, 10:16 PM.
Referenced Files
Unknown Object (File)
Sun, Jul 3, 11:09 AM
Unknown Object (File)
Sun, Jun 26, 4:55 PM
Unknown Object (File)
Wed, Jun 22, 2:28 AM
Unknown Object (File)
Tue, Jun 21, 6:35 AM
Unknown Object (File)
Mon, Jun 20, 4:27 PM
Unknown Object (File)
Sun, Jun 19, 12:50 AM
Unknown Object (File)
Thu, Jun 16, 9:40 PM
Unknown Object (File)
Sat, Jun 11, 1:10 AM


Group Reviewers
Blessed Reviewers
Test Plan


Diff Detail

rP Phabricator
Lint Skipped
Tests Skipped
Build Status
Buildable 14914
Build 19537: Run Core Tests
Build 19536: arc lint + arc unit

Event Timeline

avivey retitled this revision from to Release: start adding changerequests.
avivey updated this object.
avivey edited the test plan for this revision. (Show Details)
avivey edited edge metadata.
  • wip still

Editing, Actions, Controller, List All.

  • $release->canAcceptChangeRequests()
  • conduit .edit, .search methods
  • db migrations
  • custom fields

@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.

Check policy when requesting a new change