BMO/Meetings/2015-02-10
From MozillaWiki
- [glob] (carried forward) how should we gather/set priority for paper-cuts once the quarterly goals are done?
- we should probably pay attention to votes, and publicize this
- we'd need to track upstream and bmo bugs
- conduct a survey/similar asking people for papercuts to address?
- [mcote]: This is a good opportunity for some internal & housekeeping work, since we are delivering two awesome user-facing features and the start of another awesome developer feature. Ideas:
- Deal with admin requests one way or another; otherwise the admin dashboard has mostly been a failure (and we should acknowledge that and either fix it or ditch it).
- Testing: Taskcluster and increased test coverage.
- Agreement: A moderator-style survey, but tackle some admin stuff first.
- [glob] opsec are keen to turn off the api-dev server, let's determine a date when we can give them an all-clear
- i propose after next weeks push - 16th/17th
- All agreed.
- [mcote] Dev services are *very* anxious to turn of bzr.m.o, by end of 2015 at the latest. Is bzr.b.o a really viable option? What about launchpad or other service? What about (*gulp*) shutting it down before all releases are EOLed and relying on patches?
- [glob] this is really an upstream not a bmo issue because we no longer use bzr for anything
- getting justdave to work on bug 968636 is what needs to happen
- changing the hostname from bzr.m.o to bzr.b.o is possible, but would mean the existing sites need to |bzr switch| before they can upgrade (not a big deal imho)
- i don't think that shutting it down is an option, especially since standing up a bzr server (without loggerhead) shouldn't be a big deal
- there's a large bugzilla community infrastructure reshuffle happening right now (with recent activity from both wicked and justdave); i suspect this is the primary blocker right now
- mcote to contact justdave and get a deadline for bzr.b.o, or start thinking about a hosted solution.
- [glob] this is really an upstream not a bmo issue because we no longer use bzr for anything
- [glob] database dumps for researchers - i'll give a status update and a rough idea of what we're talking about proposing
- Whitelist of things that are public.
- Safeguard against schema changes.
- Use existing script to remove private data, then use whitelist to copy data.
- Whitelist includes bugs, email addresses, real names, attachment metadata, related tables (products, components, etc.).
- Remove users with no activity.
- Remove recent bugs (within 5 days).
- May make structural changes to make db easier to understand.
- No longer included: internal housekeeping like row IDs.
- Quarterly dumps.
- Soft deadline: end of Q2.
- GSoC project(s)?
- Dylan to sketch out a proposal for extension packaging.
