Announcing Project Bugzilla Harmony

[Dave Miller]

Here's another one I found stuck in the moderator queue when I went
looking to see what happened to Dylan's other post:

Subject:
Re: Announcing Project Bugzilla Harmony
From:
Dylan Hardison <dylan at mozilla.com <mailto:dylan at mozilla.com>>
Date:
Fri, 1 Dec 2017 10:23:57 -0500

To:
developers at bugzilla.org <mailto:developers at bugzilla.org>


> On Dec 1, 2017, at 09:56, Denis Roy <denis.roy at eclipse-foundation.org> wrote:
>
> This is great news! I will follow along and contribute however I can,
> with the very few cycles that I have 
>
> Some comments below:
>
>
> On 12/01/2017 08:20 AM, Gervase Markham wrote:
>>> Commits / Reviews / Pull Requests:
>>>
>>> Read the C4 document, that is what contributing to Bugzilla's harmony branch should be like.
>> That is a somewhat intimidating statement; see my question above. 
> +1 Not sure I follow.
>>> 4. Revert the REST API in favor of the (older) system that BMO is still using.
>> Why is that necessary? Cannot a new, improved API and the old one live
>> in parallel?
The "new" one is just a code migration from the existing one. It is "mostly" API compatible,
but we couldn't use it on BMO as there were too many differences. It is required for harmony to leave the REST API that is used on BMO alone.

To support the work Kohei is doing on the UX side, I will add an /api/ or /rest2/ endpoint
and provide new features there -- completely separate from the JSONRPC/XMLRPC/REST framework that exists now.

It is really easy to just drop in a new .cgi and support REST directly, and leave the (BMO/5.0/etc) REST system in place.

All work on APIs follows this guideline from the C4 process:

2.6. Evolution of Public Contracts

	• All Public Contracts (APIs or protocols) SHALL be documented.
	• All Public Contracts SHOULD have space for extensibility and experimentation.
	• A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
	• A patch that introduces new features SHOULD do so using new names (a new contract).
	• New contracts SHOULD be marked as "draft" until they are stable and used by real users.
	• Old contracts SHOULD be deprecated in a systematic fashion by marking them as "deprecated" and replacing them with new contracts as needed.
	• When sufficient time has passed, old deprecated contracts SHOULD be removed.
	• Old names SHALL NOT be reused by new contracts.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20180103/c579b3df/attachment.html>