Bugzilla:Meetings
Bugzilla Meetings
When and where?
We hold meetings on the 4th Wednesday of every month at 14:00 UTC.
The next meeting will be on Wednesday, 23 July 2014, at 14:00 UTC (click for time in your timezone).
You can participate in the following ways:
Via IRC: server: irc.mozilla.org channel: #bugzilla
Mozilla Vidyo: in the Bugzilla room; if you don't have Mozilla LDAP access, use this guest link: https://v.mozilla.com/flex.html?roomdirect.html&key=kCjGNHjpT8sj
Air Mozilla: https://air.mozilla.org/bugzilla-development-meeting-20140723/
Telephone: +1 650 903 0800, x92 98008 or +1 800 707 2533, pin 369 - conf 98008
Minutes will be taken at https://etherpad.mozilla.org/bugzilla-meeting and transcribed to the wiki shortly after the meeting ends.
We will try to have someone acting as a moderator on the IRC channel to summarize the discussion on IRC for those who can't watch the stream and also to relay questions from IRC to the video call.
Who can attend?
Everyone interested in being actively involved in the Bugzilla project can attend. Project leads and core developers will be there, but we welcome anyone interested in contributing, whether it be to development, testing, planning, the website, or anything else. This is not a forum for support questions, however.
What will be discussed during our next meeting (agenda)?
Wednesday, 23 July 2014
- Summary of the last meeting.
- [glob] we have a lot of webservice methods and endpoints marked as EXPERIMENTAL and UNSTABLE.
- STABLE/UNSTABLE in this context refers to the API design itself (names, parameters, results), not the stability of the code itself
- the entire REST endpoint is tagged as EXPERIMENTAL
- there appear to be no rules around when a method is upgraded to STABLE, resulting in this never happening
- i propose:
- changing from "UNSTABLE by default" to "STABLE by default" for all new methods
- [LpSolit] I disagree. You cannot know if the new methods work in an expected and useful way for 3rd-party developers till they had a chance to use them in an production (or at least test) environment. And you won't get their feedback before a release reached its stable state, i.e. x.y.0. So IMO every new API method should stay as UNSTABLE/EXPERIMENTAL for one major release (i.e. a new method included in 4.5/5.0 would be marked as STABLE in 5.2 only, unless feedback is negative enough to delay this change to 5.4).
- auditing all existing methods and marking all(?) of them as STABLE (including the whole REST endpoint)
- leading up to a major release, the release manager should audit all UNSTABLE/EXPERIMENTAL methods, and file bugs to get methods marked as STABLE or removed where appropriate
- [sgreen] Do we have a formal policy on how to handle security bugs, and when we do a point release based on them?
- [LpSolit] If the security bug is critical enough, we work on it immediately, and do sec releases asap.
- [glob] what is our process surrounding the 5.0 release, especially regarding QA testing
- Add other items here.
Summaries of previous meetings
2014
2013
2012
2011
2010
2009
Tuesday, March 10th (50th IRC meeting)
2008
Tuesday, April 8th (40th IRC meeting)
2007
Tuesday, July 10th (30th IRC meeting)
2006
Thursday, February 2nd (our first IRC meeting!)
Tuesday, June 6th (10th IRC meeting)
Tuesday, October 31st (20th IRC meeting)