View source for Bugzilla:Meetings:2014-05-28

# Summary of the [[Bugzilla:Meetings:2014-04-23|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.
# 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