Draft workflow in Gerrit will be deprecated and slated for removal.
This change is the first step in this direction.
However, the repo-tool, mainly used by Andorid developers, is still
depending on drafts and has no support for private or wip changes.
We've added '--private' and '--wip' options to the repo-tool so that
users could have alternatives after pushing drafts is rejected. But,
unfortunately, it has proved hard for us to create a new repo-tool
release containing those two new options. That means we have to find
some workarounds instead of rejecting requests for creating drafts
directly.
The most important feature of drafts is privacy (draft changes and
patch sets are only visible to the change owners and reviewers).
Luckily, we can achieve this with the help of private changes and
change edits:
1- If a user tries to create a draft change, we will create a
private change instead.
2- If a user tries to create a draft patch set, we will create a
change edit instead.
The above behaviors will be a little confusing to our users because
the change or the patch set state is inconsistent with the push
option. But they get almost the same feature. And they can use
similar operations to public their changes/edits. Before this,
they click 'Publish drafts', now they click 'Unmark private' or
'Publish edit'.
After the repo-tool supports private/wip changes, we will reject
those requests with draft option completely.
With this change, users can't create new drafts through the git push
or the 'Create Change' REST API. After this change is released, draft
changes and draft patch sets can still exist in Gerrit sites. The
existing draft changes and draft patch sets can still be published
and deleted. Some operations like cherry-pick may create a new draft
patch set if the current patch set of the target change is draft. But
after migrating existing drafts, there is no way to create a new draft
any more.
Given that Change.Status enum still contains DRAFT value and given that
patch set class still has draft flag, the draft state of changes and
patch sets can still be toggled programmatically. Thus we can keep most
drafts related unit tests until existing draft changes and draft patch
sets are migrated to non-draft changes and patch sets.
Migration path for draft changes and patch sets (will be done in
follow-up changes):
* Draft changes will be migrated to private or work-in-progress changes
* Draft patch sets will be published
During this migration, the DRAFT value will be removed from the
Change.Status enum and the draft flag will be removed from the patch set
class.
Bug: Issue 6881
Change-Id: I8663f0580b90d7ce10a597b42abecf8734d3f9b2
4b44bdc702