Code Monkey home page Code Monkey logo

Comments (3)

andygrunwald avatar andygrunwald commented on July 28, 2024 1

I'm not sure myself. It might be that we just have to make a decision, somehow.

True.

If that's the case, I think you as the project owner are in the best position to make a decision.

I am not the boss here. We are a team and contributing together on this. Only because I started this doesn't mean that I am the boss :) I often think that multiple opinions and a good discussion lead to a better result.

For reference, my local patch ...

I think your patch looks quite good.
One point we can make: Once a popular number of Gerrit instances (and i count the google instances as popular) supports this, we can implement this.
The instances I raised don't support this. Then the Avatars is empty.
We should mark the fields and methods then as a plugin field (via doc?) to make it clear that this is not a native functionality here.

After some thoughts, I think we should be pragmatic here. This is the second plugin now. I don't think that 1.000 plugins will be implemented in the next time in this lib.

Ergo: Go ahaed :)

from go-gerrit.

andygrunwald avatar andygrunwald commented on July 28, 2024

All three instances seems to be a Google hosted instances.

Other instances (not google ones) don't seem to have this plugin:

curl -s 'https://review.typo3.org/config/server/info' | grep has_avatars

curl -s 'https://gerrit.wikimedia.org/r/config/server/info' | grep has_avatars

curl -s 'https://review.openstack.org/config/server/info' | grep has_avatars

Of course we could check a couple of more non google instances. See https://en.wikipedia.org/wiki/Gerrit_(software)#Notable_users

I am thinking about a question like "How should we decide when to integrate a plugin and when not?".
What are the criteria?
Or might there be a better way of integration plugins without adding them to the complete native Gerrit code base here?
So that we don't need to think about this question about adding them or not at all, because it don't matter?

from go-gerrit.

dmitshur avatar dmitshur commented on July 28, 2024

Yes, those are good questions and we need to figure out how to answer them in order to proceed.

How should we decide when to integrate a plugin and when not? What are the criteria?

I'm not sure myself. It might be that we just have to make a decision, somehow.

If that's the case, I think you as the project owner are in the best position to make a decision.

Or might there be a better way of integration plugins without adding them to the complete native Gerrit code base here?

It would be really nice if that's the case, but I can't think of a way of making that possible at this time.

For reference, my local patch (after a bit of cleaning up) for this tries to make the Avatars field separate and documents it as only being present if the avatars plugin is enabled:

diff --git a/accounts.go b/accounts.go
index 63df455..47e9500 100644
--- a/accounts.go
+++ b/accounts.go
@@ -17,6 +17,13 @@ type AccountInfo struct {
 	Name      string `json:"name,omitempty"`
 	Email     string `json:"email,omitempty"`
 	Username  string `json:"username,omitempty"`
+
+	// Avatars lists avatars of various sizes for the account.
+	// This field is only populated if the avatars plugin is enabled.
+	Avatars []struct {
+		URL    string `json:"url,omitempty"`
+		Height int    `json:"height,omitempty"`
+	} `json:"avatars,omitempty"`
 }
 
 // SSHKeyInfo entity contains information about an SSH key of a user.
diff --git a/config.go b/config.go
index e5540f2..088b0fb 100644
--- a/config.go
+++ b/config.go
@@ -143,6 +143,7 @@ type ReceiveInfo struct {
 
 // PluginConfigInfo entity contains information about Gerrit extensions by plugins.
 type PluginConfigInfo struct {
+	// HasAvatars reports whether an avatar provider is registered.
 	HasAvatars bool `json:"has_avatars,omitempty"`
 }
 

I'm not aware of a way to make it better at this time, but I haven't thought very long about it yet.

from go-gerrit.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.