**aklapper** wrote on `2014-08-18 13:54:53 (UTC)`

So it sounds like James and Greg want separate "WMF server deployment 2014-05-29 (1.24wmf7)"-style projects for each weekly deployment.

I have not tried yet if we can add such a "deployment of the week"-project by default: "If task is closed as "resolved" in certain timeframe, automatically set project X" for the sake of getting release notes by running one Maniphest query. Need to play more with [[https://secure.phabricator.com/book/phabricator/article/herald/ | Herald]] rules which are pretty powerful.

**Question1**: If above was possible (release notes) and we automatically set such a project: If a task with that "deployment of the week"-project set is reopened (e.g. not entirely fixed) and that project entry isn't removed from the task, wouldn't the next person looking at the task interpret it as a backport request, if I understand the proposed logic correctly?

So currently the summary would currently be:
* Security issues will be handled via a "Security" project. Out of discussion/focus here.
* For non-security fixes/bugs that are candidates to backport, we are going to use projects/tags:
** "WMF_server_deployment_2014-05-29_(1.24wmf7)" (specific)
** "MediaWiki_tarball_release" (generic, we can still change that)
* People can and should follow (=receive mail notifications from Phabricator) these projects by setting up a personal [[ https://secure.phabricator.com/book/phabricator/article/herald/ | Herald ]] rule in Phabricator. **Question2**: I //do not// see a way in Herald to define a rule "Projects | name includes the string | WMF_server_deployment" though, so somebody tell me I'm wrong that this would require subscribing to each project created every week? Uhm.
* General info: Projects can be marked as archived (e.g. tarballs that have been released) so they are not offered anymore.

**Fallback:** If my questions above indeed do make things complicated, we could also start simple and stupid with a generic "Backport_to_WMF_servers" project, and could switch to a more sophisticated process later on when Phabricator provides more functionality (cf. release notes) needed.

General reminder on the old "one task can only have one task status" vs. "we have 'branches' being git master, versions on servers, and tarballs" problem: Each Project board allows custom columns, and a task can belong to more than one project.

(And now to bikeshed about our [[http://fab.wmflabs.org/project/query/advanced/ | favorite icon and color]]. Not!)