Page MenuHomePhabricator

Nominate a team in charge of deploying and maintaining Wikimedia Phabricator code
Closed, ResolvedPublic

Description

This is the team responsible of the deployment of Wikimedia Phabricator Day 1:

  • @Aklapper: phabmaster
  • @mmodell: development
  • @Rush: ops
  • @jdforrester: proxy for Product Management
  • @greg: proxy for Platform & RelEng/QA

Stakeholders (they commit to follow the project and provide feedback): @mattflaschen, @Qgil...

Additional contributors and stakeholders welcome. Share your plan.

The administrators team is related to this task, but it belongs to a different discussion.

Details

Reference
fl283

Event Timeline

flimport raised the priority of this task from to High.Sep 12 2014, 1:34 AM
flimport set Reference to fl283.

qgil wrote on 2014-05-11 00:53:42 (UTC)

We have an initial team described above.

@Aklapper leads this project. He will be the main responsible after the deployment as well, evolving his current bugmaster role. Please give us some time to define the details of the Day >1 maintenance.

A new developer from the WMF is expected to join the project as soon as we fly back from Zürich and have a chance to chat.

Other contributors may be assigned to a specific task but they don't need to be involved in the whole project (i.e. @csteipp -T314 or @demon -T159)

We have at least one volunteer developer that has expressed in Zürich his interest in getting programming tasks assigned. The door is open to more contributors and stakeholders with a declared plan. PHP developers are welcome!

I'm hoping to close this task by next Friday, having defined a core team capable of deploying "Day 1".

Swidmann wrote on 2014-05-12 08:35:14 (UTC)

Hello all,

I'm just CCed myself. I'm Stefan Widmann (Swidmann). Also known as "at least one volunteer developer". I talked to @Qgil and we thought that i should subscribe to the migration and bots stuff. I don't have a clue about bots, but I'm willing to learn. I did a lot of migration for our customers and i developed some customer specific extension so far.

If someone of you thinks: "hey that task would fit to swidmann" - feel free to CC me. Also feel free to correct my english if a phrase doesn't make sense ;)

Rush wrote on 2014-05-12 15:06:31 (UTC)

I think there are a few threads around this that would be good to weave together:

  • not knowing the timeline on this I have been getting a test instance to run things through for ops specific and especially sensitive data use cases (read: prod box) and workflow
  • dzahn I know stubbed out some puppet logic, and put some thought in this
  • I saw a few emails regarding second test instances (from whom I can't recall) being created in labs to compensate for issues / features missing in the current
  • regarding issues in the current lab instance -- I guess it depends on the future of that for how much effort we put into them?
  • mukunda is starting (today?) and I am scheduled to sync up with him as I believe Robla intends for some of his early tasks to be phabricator related (but which instance I'm not sure?)
  • I'm not entirely sure, probably just from not being in zurich, what/who is intended to migrate day 1, or if day 1 is just 'ready for migration'.

I'm pretty blown away by the organization of @Qgil regarding this, my hats off to you. This is all probably just my confusion, but I do see a bit of duplicate work around and I think we are due for a call of people who care about this / want to help? That also is probably due to my not being in zurich.

greg wrote on 2014-05-13 01:07:54 (UTC)

mukunda is starting (today?) and I am scheduled to sync up with him as I believe Robla intends for some of his early tasks to be phabricator related (but which instance I'm not sure?)

I don't think Mukunda has an account here yet otherwise I'd cc/ping him, but yes that is correct. The plan is for Mukunda to work on the prod phab install (ie: puppetization in our infra).

regarding issues in the current lab instance -- I guess it depends on the future of that for how much effort we put into them?

I *believe* the plan is for this instance to stay a testing ground, with potentially the ability for people to export/import data to the prod/real instance when it's ready.

And yeah, there was a lot of in-person chatting in Zurich about this, so we're a little behind in the "record thoughts in here" part.

aklapper wrote on 2014-05-13 07:43:48 (UTC)

dzahn I know stubbed out some puppet logic, and put some thought in this

to work on the prod phab install (ie: puppetization in our infra).

Initial patch work in https://gerrit.wikimedia.org/r/#/c/132505/

qgil wrote on 2014-05-13 13:37:29 (UTC)

I have proposed an interesting task for @Swidmann at T244: Configure inbound email for phabricator.wikimedia.org. It basically consists on rewriting the relevant parts of Scrumbugz (Python) in Phabricator. Currently this is not a task committed to Day 1, but it relies entirely on Maniphest, and it would be definitely welcomed by the teams using Trello, Mingle, and Scrumbugz. It can be developed almost in isolation from the rest of Day 1 tasks, together with the appropriate stakeholders and with advice from upstream.

not knowing the timeline on this

Day 1 is not a deadline based project, but we want to complete it as soon as it is safe to ship it. I would say that the two main tasks defining the calendar are T39: Set up permissions for Phabricator and T95: Use ElasticSearch backend for Maniphest to get stemming feature, but this is a discussion that perhaps requires an own task ("Wikimedia Phabricator Day 1 timeline"?).

I have been getting a test instance to run things through for ops specific and especially sensitive data use cases (read: prod box) and workflow

If this is for testing, ok. Otherwise, I fear that creating an ad hoc solution for RT here and now will result in less pain missing this, and in higher risk of not having RT migrated to Wikimedia Phabricator in Day 1. Please let's discuss at T63: Phabricator requires a "real name" to register.

I saw a few emails regarding second test instances (from whom I can't recall) being created in labs to compensate for issues / features missing in the current

That would be probably @Roan. Unless someone has a very good reason to maintain a third instance, I think we should focus in two: the official Wikimedia Phabricator and this Labs instance for testing and bootstrapping the official Phabricator. This is a discussion for T294: Super epic: Refactor moveToStep into a smaller function, make controllers for each step.

We need to have a first team meeting including Mukunda as soon as possible. At the end of that meeting we need to have a good idea about who is doing what in the following weeks.

mmodell wrote on 2014-05-13 18:23:20 (UTC)

So my takeaway from the meeting is that puppetizing phabricator isn't particularly pressing issue and my time/skills might be best used in coordinating with the phabricator guys on getting T95 implemented upstream. Is everyone in agreement with that? @RobLa might have a different opinion but it's definitely an area I can immediately apply myself as apposed to waiting for me to get acquainted with all of the wikimedia infrastructure and whatnot.

Working with the phabricator project is definitely something I'm comfortable doing, I've already committed code upstream in the past and I still have my phabricator dev environment ready to go.

mmodell wrote on 2014-05-13 18:24:58 (UTC)

dupe comment removed

qgil wrote on 2014-05-13 19:55:36 (UTC)

I have gone through all the tasks in our board, commenting, CCing, and assigning based on previous discussions. I have pinged potential volunteers in a couple of development tasks, and I have also moved some tasks to more appropriate columns in the board.

@Aklapper, now the ultimate coordination is all yours. I will keep working in my assigned tasks and comment as a stakeholder especially for community related topics.

hashar wrote on 2014-05-13 19:58:37 (UTC)

@mmodel , T95 is definitely a blocker for the Bugzilla migration. We have some bugs that should remain private. Another potential blocker is importing Bugzilla history =D

dzahn wrote on 2014-05-14 00:29:50 (UTC)

we did nominate a team for Bugzilla or Gerrit, instead we have different roles, people who develop code, people who deploy code and people who write puppet. we need all anyways

qgil wrote on 2014-05-14 01:28:05 (UTC)

The current team responds to the need to organize this Day 1 project, which is all about Maniphest (task / bug management). Would this correspond to the "Bugzilla team" you are referring to?

People like @Roan, @hashar, @SG, and others are focusing in the code review area. It would be great to have also certain coordination and roles there, since we don't need to wait until Day 1 to start working seriously on the Gerrit migration. Then again, if we need to improve Phabricator upstream in order to accommodate to our code review needs, then we might end up needing time from @mmodell there as well.

And remember, all these roles are related to the migration. The future teams of admins focusing on Maniphest and Differential need to be defined, although they will be an evolution of the Bugzilla and Gerrit admins, if not exactly the same people.

robla wrote on 2014-05-14 15:40:37 (UTC)

Yup, agreed this is a good first thing to get moving on. Thanks @mmodell!

qgil wrote on 2014-05-15 17:31:53 (UTC)

Team nominated and documented at https://www.mediawiki.org/wiki/Phabricator/Migration (@mmodell and @Rush, do you have user profiles at mediawiki.org? )

As of today Andre, Mukunda, and Chase are the expected maintainers after Day 1 as well. More details as we get closer to the date.

Resolving.

aklapper wrote on 2014-05-19 13:06:32 (UTC)

@mmodell: Yeah, what be awesome if you looked into T95 (https://secure.phabricator.com/T3820), importing Bugzilla, and I see that you're investigating https://secure.phabricator.com/T5096. Thanks!