Re: Announcing Project Bugzilla Harmony
Dave Miller <[email protected]> Wed, 03 Jan 2018 16:48:18 -0500
| Newsgroups | gmane.comp.bug-tracking.bugzilla.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------000208090001020106010608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 <[email protected] <mailto:[email protected]>> Date: Fri, 1 Dec 2017 10:23:57 -0500 To: [email protected] <mailto:[email protected]> > On Dec 1, 2017, at 09:56, Denis Roy <denis.roy-xUVtjUUg22pRQ0oMI7lyI3G1qET/[email protected]> 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. --------------000208090001020106010608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html><head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head><body bgcolor="#FFFFFF" text="#000000">Here's another one I found stuck in the moderator queue when I went looking to see what happened to Dylan's other post:<br> <br> <table class="header-part1" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody><tr><td><div class="headerdisplayname" style="display:inline;">Subject: </div>Re: Announcing Project Bugzilla Harmony</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">From: </div>Dylan Hardison <<a __postbox-detected-content="__postbox-detected-email" class="__postbox-detected-content __postbox-detected-email" href="mailto:[email protected]">[email protected]</a>></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Date: </div>Fri, 1 Dec 2017 10:23:57 -0500</td></tr></tbody> </table> <table class="header-part2" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody><tr><td><div class="headerdisplayname" style="display:inline;">To: </div><a __postbox-detected-content="__postbox-detected-email" class="__postbox-detected-content __postbox-detected-email" href="mailto:[email protected]">[email protected]</a></td></tr></tbody> </table> <br> <div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-size: 13px;" lang="x-unicode"><blockquote type="cite" style="color: #000000;"><pre wrap="">On Dec 1, 2017, at 09:56, Denis Roy <a class="moz-txt-link-rfc2396E" href="mailto:denis.roy-xUVtjUUg22pRQ0oMI7lyI3G1qET/[email protected]"><denis.roy-xUVtjUUg22pRQ0oMI7lyI3G1qET/[email protected]></a> wrote: This is great news! I will follow along and contribute however I can, with the very few cycles that I have <span class="moz-smiley-s2" title=":("></span> Some comments below: On 12/01/2017 08:20 AM, Gervase Markham wrote: </pre><blockquote type="cite" style="color: #000000;"><blockquote type="cite" style="color: #000000;"><pre wrap="">Commits / Reviews / Pull Requests: Read the C4 document, that is what contributing to Bugzilla's harmony branch should be like. </pre></blockquote><pre wrap="">That is a somewhat intimidating statement; see my question above. </pre></blockquote><pre wrap="">+1 Not sure I follow. </pre><blockquote type="cite" style="color: #000000;"><blockquote type="cite" style="color: #000000;"><pre wrap="">4. Revert the REST API in favor of the (older) system that BMO is still using. </pre></blockquote><pre wrap="">Why is that necessary? Cannot a new, improved API and the old one live in parallel? </pre></blockquote></blockquote><pre wrap="">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 <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>api<span class="moz-txt-tag">/</span></i> 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. </pre></div> <br> </body></html> --------------000208090001020106010608--