Move (some) download commands back to Gerrit core?

[Saša Živkov]

Exposing DownloadCommand extension point is for sure valuable as plugins can contribute

(additional) download commands.

.

However, why did we externalise all download commands into the download-commands plugin?

Even if it is a core plugin, it is still a plugin so it is optional.

Who runs Gerrit without the basic download commands?

I mean, someone may not run the replication plugin or the reviewnotes plugin but running

Gerrit without download commands just makes no sense.

Why don't we internalise the basic download commands (clone, download patch-set, cherry-pick patch-set, ...) back into Gerrit core?

Of course the extension point should still stay so that plugin can contribute further download commands.

[Sven Selberg]

Good question, I feel the same way.

The only instance I can think of where you perhaps need to change the download commands

is if you have a mirror cluster where you want your user to fetch code from then you might want

to have the URL of the lb for the cluster instead of the URL for the master. If there is such a use case

we could perhaps make the download URL configurable?

[Saša Živkov]

On Tue, Oct 17, 2017 at 9:42 AM, Sven Selberg <sven.s...@axis.com> wrote:

Good question, I feel the same way.

The only instance I can think of where you perhaps need to change the download commands

is if you have a mirror cluster where you want your user to fetch code from then you might want

to have the URL of the lb for the cluster instead of the URL for the master. If there is such a use case

we could perhaps make the download URL configurable?

Yes, it could be done. I see your proposal as an additional feature not directly related to whether download commands

are contributed by the core or by the plugin. Right?

On Monday, October 16, 2017 at 10:17:57 PM UTC+2, zivkov wrote:

Exposing DownloadCommand extension point is for sure valuable as plugins can contribute

(additional) download commands.

.

However, why did we externalise all download commands into the download-commands plugin?

Even if it is a core plugin, it is still a plugin so it is optional.

Who runs Gerrit without the basic download commands?

I mean, someone may not run the replication plugin or the reviewnotes plugin but running

Gerrit without download commands just makes no sense.

Why don't we internalise the basic download commands (clone, download patch-set, cherry-pick patch-set, ...) back into Gerrit core?

Of course the extension point should still stay so that plugin can contribute further download commands.

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sven Selberg]

On Tuesday, October 17, 2017 at 10:28:46 AM UTC+2, zivkov wrote:

On Tue, Oct 17, 2017 at 9:42 AM, Sven Selberg <sven.s...@axis.com> wrote:

Good question, I feel the same way.

The only instance I can think of where you perhaps need to change the download commands

is if you have a mirror cluster where you want your user to fetch code from then you might want

to have the URL of the lb for the cluster instead of the URL for the master. If there is such a use case

we could perhaps make the download URL configurable?

Yes, it could be done. I see your proposal as an additional feature not directly related to whether

download commands

are contributed by the core or by the plugin. Right?

Correct.

You could make fetch URLs configurable in the plugin without making it core Functionality, and IMO you

can make it core functionality without making fetch URLs configurable.

So it's one big +2 for the idea of having the download-commands plugin functionality in core Gerrit either way!

/Sven

[Martin Fick]

On Monday, October 16, 2017 10:17:11 PM Saša Živkov wrote:
> Even if it is a core plugin, it is still a plugin so it is
> optional. Who runs Gerrit without the basic download
> commands? I mean, someone may not run the replication
> plugin or the reviewnotes plugin but running
> Gerrit without download commands just makes no sense.

There are many reasons to keep (and push more stuff to move)
plugins, even if we feel they are important as part of
Gerrit by default. A few of the reasons are, the ability to
customize things, release things independently (bug fixes),
remove them for a reduced attack surface (many people use
Gerrit as a Git server with ACLs, and have no need for the
UI, so why would they want UI plugins), or a reduced memory
footprint... Core plugins are meant as the mechanism to
keep them by default.

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[Saša Živkov]

On Tue, Oct 17, 2017 at 3:55 PM, Martin Fick <mf...@codeaurora.org> wrote:

On Monday, October 16, 2017 10:17:11 PM Saša Živkov wrote:
> Even if it is a core plugin, it is still a plugin so it is
> optional. Who runs Gerrit without the basic download
> commands? I mean, someone may not run the replication
> plugin or the reviewnotes plugin but running
> Gerrit without download commands just makes no sense.

There are many reasons to keep (and push more stuff to move)
plugins, even if we feel they are important as part of
Gerrit by default.  A few of the reasons are, the ability to
customize things, release things independently (bug fixes),

I understand your points but if we keep moving more and more stuff into plugins the ultimate question is:

What is (core) Gerrit?

Shall Gerrit ultimately become just a plugin manager?

IMHO, Gerrit is primarily a code review system and a core feature of

a code review system is being able to download changes in review.

Without the download-commands plugin Gerrit is not a useable code review system.

On the other side it is useable without other core plugins (replicaiton, reviewnotes, singleusergroup, ...)

remove them for a reduced attack surface (many people use
Gerrit as a Git server with ACLs, and have no need for the 

UI, so why would they want UI plugins), or a reduced memory

IIRC, the headless mode disables UI but it doesn't disable REST API.

Shall REST API be moved out into a plugin too, to further optimize for the "Git server with ACLs" use-case?

Shall UI be moved into a plugin too?

[Sven Selberg]

On Tuesday, October 17, 2017 at 3:55:39 PM UTC+2, MartinFick wrote:

On Monday, October 16, 2017 10:17:11 PM Saša Živkov wrote:
> Even if it is a core plugin, it is still a plugin so it is
> optional. Who runs Gerrit without the basic download
> commands? I mean, someone may not run the replication
> plugin or the reviewnotes plugin but running
> Gerrit without download commands just makes no sense.

There are many reasons to keep (and push more stuff to move)
plugins, even if we feel they are important as part of
Gerrit by default.  A few of the reasons are, the ability to
customize things, release things independently (bug fixes),
remove them for a reduced attack surface (many people use
Gerrit as a Git server with ACLs, and have no need for the
UI, so why would they want UI plugins), or a reduced memory

Just for clarity: download-commands does not provide any UI elements,

it populates collections in json objects provided by the REST API.

[Martin Fick]

On Wednesday, October 18, 2017 11:13:37 AM Saša Živkov
wrote:

> On Tue, Oct 17, 2017 at 3:55 PM, Martin Fick
<mf...@codeaurora.org> wrote:
> > On Monday, October 16, 2017 10:17:11 PM Saša Živkov
wrote:
> > > Even if it is a core plugin, it is still a plugin so
> > > it is optional. Who runs Gerrit without the basic
> > > download commands? I mean, someone may not run the
> > > replication plugin or the reviewnotes plugin but
> > > running
> > > Gerrit without download commands just makes no sense.
> >
> > There are many reasons to keep (and push more stuff to
> > move) plugins, even if we feel they are important as
> > part of Gerrit by default. A few of the reasons are,
> > the ability to customize things, release things
> > independently (bug fixes),
> I understand your points but if we keep moving more and
> more stuff into plugins the ultimate question is:
> What is (core) Gerrit?

Glad you asked. I would argue that the most valuable
fundamental piece of Gerrit is actually the git server,
likely that includes the ACL mechanism. But I can imagine
even that being pluggable to be able to have simpler
mechanisms available. Gerrit provides one of the best git
servers in the world, likely the most configurable. Many
people use Gerrit only for this. We use it that way in many
places despite also using it for code review in other
places. One could say that a Gerrit slave is not much more
than that.

I think that if it were possible to build Gerrit as a git
server only which accepted plugins, without code review,
that it would likely get used by more people, and more
projects. For example, some people may want to run gitiles
without running code review, but without loosing the ability
to have ACLs. If this were feasible, it would likely be
more appealing to some since it would mean running a much
reduced jvm footprint, and a simpler codebase to work with.
If this indeed increases the usage of Gerrit, I suspect that
the core git serving features of Gerrit would get more
robust, by virtue of likely seeing an increase in
contributions due to an increase in users.

Now you might say, such a beast is not Gerrit, and that is
probably a valid point. Does that mean that such a beast
would not be a good building block for Gerrit to build upon?
If we has such a beast, what would we call it? Maybe "Grit"
(for a shorter Gerrit) or GGIT? :)

> REST API. Shall REST API be moved out into a plugin too,
> to further optimize for the "Git server with ACLs"
> use-case?
> Shall UI be moved into a plugin too?

Yes, you read my mind. After all, as mentioned above, those
feature are already ignored by many people,

[Luca Milanesio]

+1 to that !

It was one of my points during the last Gerrit User Summit 2017 in London: a *LOT* of people would just use Gerrit as a very stable, powerful and scalable Git server. Why don't we give a UX (or not a UX and just headless packaging) for that?

 For example, some people may want to run gitiles 
without running code review, but without loosing the ability 
to have ACLs.

Yes, exactly my point.

 If this were feasible, it would likely be 
more appealing to some since it would mean running a much 
reduced jvm footprint, and a simpler codebase to work with.  
If this indeed increases the usage of Gerrit, I suspect that 
the core git serving features of Gerrit would get more 
robust, by virtue of likely seeing an increase in 
contributions due to an increase in users.

This for sure !

Now you might say, such a beast is not Gerrit, and that is 
probably a valid point.  Does that mean that such a beast 
would not be a good building block for Gerrit to build upon?
If we has such a beast, what would we call it?  Maybe "Grit" 
(for a shorter Gerrit) or GGIT? :)

REST API. Shall REST API be moved out into a plugin too,
to further optimize for the "Git server with ACLs"
use-case?
Shall UI be moved into a plugin too?

Yes, you read my mind.  After all, as mentioned above, those 
feature are already ignored by many people,

To be honest with you, with PolyGerrit we're not that far at all !

The PolyGerrit Team is already developing the UI as a separate project, it wouldn't be difficult to have it as a separate component altogether.

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation

-- 
-- 
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[Sven Selberg]

If we were to build a headless variant for the use cases described above we could have the download commands as part of core Gerrit but not of core Grit (a name which I sort of liked...) and everyone would be happy, right?

[Saša Živkov]

OK, use Git-server + access rights but don't call it Gerrit Code Review.

Providing just a Git server + access rights, as a build artifact

out of Gerrit's source tree would be one option to achieve what you want.

And I have really nothing against this option if someone wants to work on it.

Maybe you even want to propose a new project which contains only Git-server

and access rights? Then publish it on maven central and build Gerrit Code Review

on top of that?

However, I cannot imagine something called "Gerrit Code Review" which doesn't include a UI.

Either product's name is wrong or its main feature is missing.

Gerrit Code Review is not a just plugin container which happens to include some UI plugin.

Gerrit Code Review is defined and distinguished from other products by its Code Review UI (and all other code-review features).

Back to my original post:

I still believe that it makes no sense that Gerrit core supports uploading of changes

for review but requires a plugin to provide downloading of these changes.