Page MenuHomePhabricator

Create project tag to track Toolforge Build Service beta release
Closed, ResolvedPublic

Description

Name:
tbs-beta

Type of project:
Goal

Description
Beta rollout of wmcs toolforge build service

Event Timeline

@Aklapper can you assist with this.

I tried following the directions from last year here: T317006

Aklapper moved this task from Incoming to Projects to create on the Project-Admins board.

Hi, see https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects linked from the Phabricator frontpage. :)
Where to find more public information about "toolforge build service"? Also, tbs-beta is quite cryptic (but could be an additional project tag).

Where to find more public information about "toolforge build service"?

Toolforge Build Service

Also, tbs-beta is quite cryptic (but could be an additional project tag).

Agreed. Maybe the beta tracking tag should be a milestone under Toolforge Build Service too to keep things connected?

Hi, see https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects linked from the Phabricator frontpage. :)
Where to find more public information about "toolforge build service"? Also, tbs-beta is quite cryptic (but could be an additional project tag).

I discussed the name with david.
He suggested tbs-beta because we already have several tbs-* naming conventions(there's an alias named tbs) and this makes sense to me.

We'll adding more public info about toolforge build service soon.

Where to find more public information about "toolforge build service"?

Toolforge Build Service

Also, tbs-beta is quite cryptic (but could be an additional project tag).

Agreed. Maybe the beta tracking tag should be a milestone under Toolforge Build Service too to keep things connected?

That's a good suggestion. @dcaro will this work for us?

Agreed. Maybe the beta tracking tag should be a milestone under Toolforge Build Service too to keep things connected?

That's a good suggestion. @dcaro will this work for us?

We are using milestones to track the iterations already, I don't know enough on how milestones work in phabricator to be able to tell if it will be an issue or not (I don't have permissions to play around with them either).
It looks to me that phabricator expects the milestones to be sequential, and that might not work (as we would have the iteration14 + beta milestones in parallel).
@KHernandez-WMF might know better if that might be an issue.

About the tags, we usually have something like tbs14 and tbscurrent pointing to Toolforge Build Service (Iteration 14). Just noted though that when specifying a tag, it will autocomplete by the tag, even if it shows the name, so typing #+toolforgebuildservice does not match the iterations, so I'll start adding the long tags there too.

For users, they probably know the long name, so having the long tag is a must, though I don't think that having the short alias has any downside.

I don't know enough on how milestones work in phabricator to be able to tell if it will be an issue or not

https://www.mediawiki.org/wiki/Phabricator/Project_management#Parent_Projects,_Subprojects_and_Milestones (it's complicated)

(I don't have permissions to play around with them either).

Per https://www.mediawiki.org/wiki/Phabricator/Help , "If you want to test Phabricator, use the Cloud Services instance."

It looks to me that phabricator expects the milestones to be sequential, and that might not work (as we would have the iteration14 + beta milestones in parallel).

Tasks in a milestone cannot be in another milestone of the same parent project, or in another column on the parent project workboard than the milestone column so this would collide with iteration milestones.

If we went for a subproject instead of a milestone, Tasks in subprojects will not show up on the workboard of the parent project and Milestones will show up in the board of the associated subproject. (Also, creating a project's first subproject moves all members to become members of the subproject instead but that's usually not an issue.)

You can assign a task to both a milestone of a parent project and a subproject of the parent project though, see https://phab.wmflabs.org/T105 : You'd see the task both on the subproject workboard at https://phab.wmflabs.org/project/board/53/ and (if daemons were running properly on that test instance) in theory also in the milestone column of the parent workboard at https://phab.wmflabs.org/project/board/52/

#

(I don't have permissions to play around with them either).

Per https://www.mediawiki.org/wiki/Phabricator/Help , "If you want to test Phabricator, use the Cloud Services instance."

I did not know that existed :), just created a new account there, thanks!

It looks to me that phabricator expects the milestones to be sequential, and that might not work (as we would have the iteration14 + beta milestones in parallel).

Tasks in a milestone cannot be in another milestone of the same parent project, or in another column on the parent project workboard than the milestone column so this would collide with iteration milestones.

If we went for a subproject instead of a milestone, Tasks in subprojects will not show up on the workboard of the parent project and Milestones will show up in the board of the associated subproject. (Also, creating a project's first subproject moves all members to become members of the subproject instead but that's usually not an issue.)

I think this would be ok, we want it for the feedback the users will create, not to track the work we do, so it's ok if the tasks don't show up on the parent project.

You can assign a task to both a milestone of a parent project and a subproject of the parent project though, see https://phab.wmflabs.org/T105 : You'd see the task both on the subproject workboard at https://phab.wmflabs.org/project/board/53/ and (if daemons were running properly on that test instance) in theory also in the milestone column of the parent workboard at https://phab.wmflabs.org/project/board/52/

That'd be great too, as we work on milestones (each iteration is a new one), we can have the task created on the subproject, for the user feedback, and even a board with all the user feedback, and still put in it the current iteration for us to work on.

Sounds to me that the subproject might be the more convenient one for us to use :)

You can assign a task to both a milestone of a parent project and a subproject of the parent project though, see https://phab.wmflabs.org/T105 : You'd see the task both on the subproject workboard at https://phab.wmflabs.org/project/board/53/ and (if daemons were running properly on that test instance) in theory also in the milestone column of the parent workboard at https://phab.wmflabs.org/project/board/52/

From what I've read + purpose of this, it does sound like this is the best option. The subproject would become beta release then, to collect user feedback - I can set it up @dcaro. I will let @komla know so he can set up columns/tasks if he needs to there.

So if we create a subproject, then the parent project cannot specify members anymore. Instead, the members of all subprojects are treated as being the parent project's members. I'm not sure this side effect is welcome, as a "Toolforge Build Service beta release" subproject would likely get archived at some point? But might not matter?

Aklapper assigned this task to KHernandez-WMF.