Bugzilla:Meetings:2014-05-28
From MozillaWiki
- Summary of the last meeting.
- 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.
- 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.
- 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.
- All agreed to
- 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.
- 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
