Page MenuHomePhabricator

Release: start adding changerequests
Changes PlannedPublic

Authored by avivey on Dec 9 2016, 10:16 PM.
Tags
None
Referenced Files
F14078283: D17020.diff
Fri, Nov 22, 3:05 AM
Unknown Object (File)
Wed, Nov 20, 3:39 PM
Unknown Object (File)
Sat, Nov 16, 3:40 PM
Unknown Object (File)
Thu, Nov 14, 7:10 PM
Unknown Object (File)
Thu, Nov 14, 5:38 AM
Unknown Object (File)
Tue, Nov 12, 7:24 PM
Unknown Object (File)
Tue, Nov 12, 6:33 PM
Unknown Object (File)
Tue, Nov 12, 6:32 PM

Details

Reviewers
None
Group Reviewers
Blessed Reviewers
Test Plan

tbd

Diff Detail

Repository
rP Phabricator
Branch
upstream-release
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 14833
Build 19409: Run Core Tests
Build 19408: 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
  • add TODO and OPEN QUESTIONS

@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