**aklapper** wrote on `2014-06-06 17:14:12 (UTC)`

Spent the afternoon thinking about this item. Please show me that I'm wrong and that this can be made less complex.

**Underlying assumptions:**
* On branching for a new //xx// in //WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd)//: No fix for a task / commit can be included in //WMF server deployment 1.xx-wmfZZ// which would not also automatically be included in //tarball 1.xx-rc// or //tarball 1.xx.0//. In other words: When switching from //WMF server deployment 1.23-wmf26// to //WMF server deployment 1.24-wmf0//, the //tarball// branch for 1.23 gets created at the very same time.
* The term ''version'' in the rest of this comment refers to a string like //1.xx.y// or //1.xx-wmfZZ// or //Sprint 1// or //yyyy-mm-dd//. It might also be an //iteration// or a //sprint// (simplified as several //iterations// can become a //release// / //version//, but I really got to start somewhere).
* We do not rename projects which include versioning in their names as it would make ChangeLog creation (and burndown charts?) impossible. Discussed above in T166.

**Situations we face:**
 * Planning to fix a task in a future version (//WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd)//, would automatically also end up in //tarball 1.xx.0//)
 * Planning to fix a task in a past version (backporting to servers; only applies for //WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd)//)
 * Documenting that a task got resolved in a timeframe (cf. ChangeLog), hence fixed in //WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd)//, would automatically also end up in //tarball 1.xx.0//. (TODO: No idea if this could be set automatically, but that would be lovely.)
 * Documenting that a task planned for a version (well, rather explicitly //sprint// in this case) was planned but did //not// get resolved in that timeframe.

**Conflict about interpreting versions (//affected// vs //fixed in//):**
* If we reflect //versions// in or via //project names//, we easily end up with a semantic conflict when the task is closed as resolved: Was that version //affected// by the bug reported in the task? Or did that version include a //fix// for the bug reported in the task?
* I tend towards using //Versions which include a fix for a problem/task// because planning is more important in a task management tool than info about the version used by the task's reporter. This must be clearly expressed in our docs (T350).
* Making this clear is also important for projects with sprints / release cycles not aligned with WMF deployment cycles (also keep 3rd party development in mind).

**Getting notified about backporting requests (T167):**
 * Refering to the situation //Planning to fix a task in a past version (backporting to servers)//; the third assumption says //We do not rename projects which include versioning in their names//.
 * In practice it means that when 1.xx-wmfZZ gets deployed on the first WMF servers, Release Management (Greg etc) would have to subscribe via Herald to watch the project //WMF server deployment 1.xx-wmfZZ// in order to get notifications whenever a task is added to that project (= a request to backport).
 * The same thing would happen every 7 days (for //WMF server deployment 1.xx-wmfZZ+1//, etc.) which sounds really cumbersome and error-prone.
 * Instead we might want to have a "static"/"generic" //Backport to WMF// project so people don't have to subscribe to its notifications every week?
 * Once a backport has been granted and merged, the task must be edited by removing the //Backport to WMF// project and by adding the //WMF server deployment 1.xx-wmfZZ// project. Disadvantage here: We'd lose statistics on how often we need to backport stuff.
 * TODO: We might also have to document that the task whose fix should get backported must remain open (T350), not sure how flexible the notification system is.)

Based on that above assumptions can be considered correct, we might end up with these things //in parallel//:
 * generic projects: //MediaWiki// (covered in T68; task reporters are encouraged to set them)
 * sprint/iteration projects: //Team XYZ Sprint 23 (2014-05-08)//
 * WMF server deployment projects: //Fixed in WMF server deployment 1.xx-wmfZZ//
 * One generic WMF backport request project release management should subscribe to: //Backport to WMF servers//
 * For projects not following the WMF server deployment or MediaWiki tarball release schedule: //Fixed in $projectname x.y.z//

Tarball release projects (like //MediaWiki release 1.xx.y//) for fixed/resolved tasks would not be needed if the aforementioned first assumption on branching holds true, as one could query for all tasks in project //WMF server deployment 1.xx-wmfZZ// where 0 ≤ ZZ ≤ 26. 
Though I am not convinced if that would be discoverable enough to 3rd party MediaWiki users in order to find out in which tarball version a fix is supposed to be included - TODO: might need to document that.

So.... does this novel make any sense?