BMO/Meetings/2013-05-21

Jenkins

• If prod Jenkins still isn't working, do we ignore the 500 error on the client side or use a staging server? How long until we get that working, and how long should we continue to write to Tinderbox as well? Either way, we need to update bug 527038 with the plan.

dkl - Tinderbox server shutdown progress: We report test results to jenkins. This makes jenkins break. They upgraded it, it broke other things, so they downgraded it again. Brandon b. proposed outsourcing this to an extermal system, to TravisCI. They support Perl very well. Mozbase uses it. But for now, they could put the upgraded version of the plugin on the staging server and we use that. That will get us off dependency on Tinderbox. Eventually, get someone to fix the Java plugin in Jenkins that broke with the upgrade instead of rolling it back.

Tracking flags

• Deployed to bugzilla-dev.allizom.org. Is the migration script ready? If so, has it been run on bugzilla-dev? If not, should we delay calling for testers until it has been run? Or create new-style testing flags for comparison?

dkl - Tracking flags extension pushed to bugzilla-dev. We won't do the migration there but some fields are added for testing purposes. The migration will require some minor changes to the templates for compatibility. It has to be timed. This push is just for testing. Should we ask on dev-planning for testers? Probably should ask b2g folks to come test it.

Native REST API

• Debate raging in bug 866927. Let's work with upstream Bugzilla to resolve this.

Discussion:

Native REST API.

• The goal is to make the REST api part of bugzilla instead of having it be a separate service on a separate server. We are at the review stage of the project.
• we have a (partial?) list of what is different between the two.
• goal, keep data format same as it is now, but give people a new way to get to it.

then make an extension to manipulate the data to look like the bzapi so people can choose different paths into the api.

• the api wasn't newbie friendly for the native api, assumed you already knew how rpc worked. while the REST stuff had better documentation so had better uptake.
• upstream api couldn't do stuff that the bzapi does with screen scraping and so on. full search isn't possible yet. it wouldn't take that much work to implement it.
• will bzapi support be included? yes. it isn't a choice between one or the other - the plan is to support both endpoints. Supporting/maintaining two apis is more complicated, but the bzapi uses some of the same key names as upstream. we use a different path to get to it. Later, we have to consider how to combine the data structure. Making sure that upstream is backwards compatible will be hard because of the same key names and different data structure. we can just change the key names.
• We could have a different endpoint for each version (justdave)
• glob - merge it. have a bzapi compatible endpoint and an upstream compatible endpoint.
• dkl - or update the upstream api to more closely match the bzapi with a single endpoint. if we do what justdave suggests and have versioning on the api we could document it well as it updates.

the version number would be part of the endpoint so that the different endpoints keep everyone happy. do it as an extension for now.

• further discussion on IRC with gerv just after the meeting.

Public ES database

• Waiting on metrics, but in the mean time, any guesses as to the questions in bug 872363?

Kyle has been looking at data about patches. May 14th entry http://people.mozilla.com/~klahnakoski/test/

Transitive closure hierarchies are cool.

Triage session

• Any ideas for tackling the existing BMO bugs? One by one in a marathon (or in several) sessions? How do we sort them? (Probably needs another metameeting, since the last just introduced the topic).
  • I'm happy to take this, and can work on setting up something tomorrow that will at least help frame what needs to be done and how we can do it. Here is a preliminary outline for BMO bug triage. https://etherpad.mozilla.org/bmo-bug-triage - lizzard

• upcoming bug days for good first bugs and for support.mozilla.org - lizzard

• asked people to clear out their old or non-useful shared searches. There were 562 shared searches (at least). Now there are 391. I guess it's not that different. Got a lot of interesting feedback on what people want out of shared searches.

User Profiles

glob made some progress on user profiles. We have 466K users. It takes 25 minutes to run through all the 55K active users. 76 minutes for all 466K.

ReviewBoard

• Seriously eyeballing ReviewBoard as a Splinter replacement.

glob - ReviewBoard is pretty good. We can deploy it internally. Can it be supported with same level of uptime as we can for bugzilla? It's a django/python/mysql/apache/memcache setup. We would need to customize it and it needs a security review. Longer delivery time than using the tool that webkit uses. It supports perl, it shows functions, shows me other files in the repo, etc. You set up the repos and the base directories. Github projects could be supported at least reviewing patches from pull requests but the full context may not be there.