Incompatible change in 2.1.7: ChangeDetailService

10 views
Skip to first unread message

Sascha Scholz

unread,
Jun 1, 2011, 9:33:29 AM6/1/11
to repo-d...@googlegroups.com
Hi,

the ChangeDetailService interface has changed in Gerrit 2.1.7, see
https://review.source.android.com/#change,22769.

The Mylyn Gerrit connector connects to this Gerrit service with
JSON-RPC. With this incompatible interface it's very cumbersome to be
compatible with different Gerrit versions. The reason is that we use
Gerrit interfaces and classes directly in our codebase. We have a
temporary workaround in place, but are seeking for a more permanent
solution for accessing Gerrit.

I heard that there are good chances that you provide a stable API for
accessing Gerrit data in the future. Until to then, would it be
possible to keep existing remote interfaces stable (i.e. that you only
extend them if needed?). Or do you have a better idea / suggestion for
us?

Regards,
Sascha

[1] Mylyn Reviews issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=347405

Shawn Pearce

unread,
Jun 1, 2011, 10:11:45 AM6/1/11
to Sascha Scholz, repo-discuss
On Wed, Jun 1, 2011 at 06:33, Sascha Scholz <sascha...@gmail.com> wrote:
> the ChangeDetailService interface has changed in Gerrit 2.1.7, see
> https://review.source.android.com/#change,22769.

Ouch.

> The Mylyn Gerrit connector connects to this Gerrit service with
> JSON-RPC. With this incompatible interface it's very cumbersome to be
> compatible with different Gerrit versions. The reason is that we use
> Gerrit interfaces and classes directly in our codebase. We have a
> temporary workaround in place, but are seeking for a more permanent
> solution for accessing Gerrit.
>
> I heard that there are good chances that you provide a stable API for
> accessing Gerrit data in the future. Until to then, would it be
> possible to keep existing remote interfaces stable (i.e. that you only
> extend them if needed?). Or do you have a better idea / suggestion for
> us?

I propose changing the current method to suffix with "2" and restoring
the old method. If someone sends me a change to do this on the
"stable" branch, I am willing to spin 2.1.7.1 and 2.2.0.1 with this
change pretty quickly. Mylyn should then just encourage users to make
sure their servers aren't using the bad 2.1.7/2.2.0 releases.

We'll try harder not to break the JSON-RPC interface in future
releases. But I want to focus on the Git storage backend. Ideally we
will extract most of the relevant Git-storage code from Gerrit Code
Review itself, move them to be a sub-part of JGit, and Mylyn can speak
to Gerrit over the Git transport protocols. We're probably a year away
from having all of that working very well, but that is my long-term
approach for interacting with Gerrit programatically. We already have
most of that in place for the project access controls in 2.2.0... we
just need to extract the relevant classes out of Gerrit.

Sascha Scholz

unread,
Jun 1, 2011, 10:19:21 AM6/1/11
to Shawn Pearce, repo-discuss
Hi

On Wed, Jun 1, 2011 at 4:11 PM, Shawn Pearce <s...@google.com> wrote:
> On Wed, Jun 1, 2011 at 06:33, Sascha Scholz <sascha...@gmail.com> wrote:
>> the ChangeDetailService interface has changed in Gerrit 2.1.7, see
>> https://review.source.android.com/#change,22769.
>
> Ouch.
>

> I propose changing the current method to suffix with "2" and restoring
> the old method. If someone sends me a change to do this on the
> "stable" branch, I am willing to spin 2.1.7.1 and 2.2.0.1 with this
> change pretty quickly. Mylyn should then just encourage users to make
> sure their servers aren't using the bad 2.1.7/2.2.0 releases.

Let's see if I can be this 'someone'. ;-)

> We'll try harder not to break the JSON-RPC interface in future
> releases. But I want to focus on the Git storage backend. Ideally we
> will extract most of the relevant Git-storage code from Gerrit Code
> Review itself, move them to be a sub-part of JGit, and Mylyn can speak
> to Gerrit over the Git transport protocols. We're probably a year away
> from having all of that working very well, but that is my long-term
> approach for interacting with Gerrit programatically. We already have
> most of that in place for the project access controls in 2.2.0... we
> just need to extract the relevant classes out of Gerrit.
>

Sounds good, although I would be happy to have this a bit earlier than
one year from now on.

Sascha

Shawn Pearce

unread,
Jun 1, 2011, 10:45:26 AM6/1/11
to Sascha Scholz, repo-discuss
On Wed, Jun 1, 2011 at 07:19, Sascha Scholz <sascha...@gmail.com> wrote:
>> We'll try harder not to break the JSON-RPC interface in future
>> releases. But I want to focus on the Git storage backend. Ideally we
>> will extract most of the relevant Git-storage code from Gerrit Code
>> Review itself, move them to be a sub-part of JGit, and Mylyn can speak
>> to Gerrit over the Git transport protocols. We're probably a year away
>> from having all of that working very well, but that is my long-term
>> approach for interacting with Gerrit programatically. We already have
>> most of that in place for the project access controls in 2.2.0... we
>> just need to extract the relevant classes out of Gerrit.
>
> Sounds good, although I would be happy to have this a bit earlier than
> one year from now on.

I would too. But moving out of our SQL storage system and into Git
isn't going to happen overnight. I wish it were that simple. I'm just
hand waving here and saying I hope to have it done before the end of
2011. I'd love to finish it before the end of this summer... but the
realist in me isn't sure that will be possible given everything else I
also need to get done by the end of the summer.

Reply all
Reply to author
Forward
0 new messages