From MozillaWiki
Jump to: navigation, search
  1. Summary of the last meeting.
  2. Ship more often, tied to dates, not features?
    • Agreement on aiming for releases approximately every 6 months.
    • Version numbers will depend on the content of the release, following standard versioning semantics:
      • Major versions have breaking changes, large schema changes, or large UI changes.
      • Minor versions have smaller features and noncritical bug fixes.
      • Patch releases have critical bug fixes, particularly with regards to security.
    • It could be argued that it's nice to not release too many major versions in a row, but if we keep three supported releases, users won't have to upgrade for a year and a half. No sense in delaying breaking features if they will bring value.
    • Release a new version sooner?
      • As it stands, 5.0 roadmap items will probably not all be finished before August, meaning release around October.
      • We have several features that have been ready (and deployed to BMO) for many months, including caching and REST support.
      • Due to perl version increase requirements, this should really be a major version bump.
      • proposal: release current master as 5.0, and 6.0 in six months for yui3, markdown, and sandstone.
        • Target 6.0 as a "majorish" breaking change, notify people that 6.0 is coming soon, and they may want to wait/prepare for 6.0. (sites on 4.2 or earlier should be advised to upgrade to 4.4 to ensure continued support).
    • Deprecation of xmlrpc/jsonrpc webservices:
      • Mark them as deprecated in 5.0.
      • Remove one year later (this gives sites 2 full years to shift).
      • Discussion around the actual implementation of how to remove the old endpoints (just remove the code, or refactor around REST)
    • All attendees are in favor of
      • Releasing 5.0 soon (in a month or two) (for perl bump, memcached, REST) with good warnings about what is going to break in the future
      • Releasing 6.0 in ~6 months (for yui3, sandstone, markdown), since yui3 can be considered breaking.
  3. Drop support from three to two releases? Starting with Bugzilla 5.0 (EOL after 5.4 released)?
    • If we start doing two releases a year, supporting only two releases requires an upgrade once a year, which is probably too much.
    • All agree to keep supporting three releases.
  4. Should we drop some of bugzilla's many social media accounts? specifically the g+ and facebook groups seem like a trap for people expecting to get support there
    • All agreed to
      • delete the facebook and google+ groups/communities
      • ensure there are FaceBook and Google+ pages (not groups).
      • Mark those pages with the actual contact info of the Bugzilla community.
  5. Use a keyword to indicate that a bug has been triaged? Otherwise we'll get lost.
    • Doesn't work well if we do yearly triages, since we would need another keyword.
    • Instead, assign triaging by components, splitting large components (200 or more bugs) into groups of 100, by bug ID.
    • mcote will do this before next triage party on June 4.
  6. Other items
    • Still waiting on a bunch of people to approval to re-license the documentation (including justdave...)
    • f1sh is still interested in working on porting BMO's sandstone skin to Bugzilla, but won't have time until after June.
    • Moving forward with migration of bugzilla.org to a CMS. Have a volunteer willing to port the content. Targeting a staging site as we have dynamic content requirements which require a security review.
    • bugsahoy and whatcanidoformozilla.org now includes bugzilla and perl bugs