Open Stack

On 3/17/14, 3:43 PM, "Clint Byrum" <clint at fewbar.com> wrote:

>According to ohloh.net:
>
>http://www.ohloh.net/p/android - 576 developers
>http://www.ohloh.net/p/mediawiki - 233 developers
>http://www.ohloh.net/p/openstack - 1556 developers

These numbers only tell part of the total. There are 3 major Android
projects that are using gerrit (one of which is google¹s android project
itself). This total close to 1700 developers.

As for mediawiki, the base mediawiki code is only a portion of what is
managed by their Gerrit install. They have almost 400 independent projects
managed in their system.

Yes code wise for an individual project, OpenStack has more contributors,
but when it comes to the mass of the Gerrit install, ours is still much
smaller.

This is part of what leads us to be considered smaller. Both of the
aforementioned projects not only run their own development, but from the
contributor list from gerrit itself, members of the projects account for
almost 75% of the development of Gerrit if not more. If we picked up
contributing on a steady basis to their repositories, we would have more
of a say in the process. I am just not convinced that adding to a
monolithic Java application is worth our time.

Yes, there are contributors to OpenStack that are learning python and have
focused more in the past on Java development, but I would think they would
be in the minority when it comes to the community as a whole.

>Is it unreasonable to try and add a better system for extending and
>integrating with Gerrit? I go back to the fact that the challenge for a
>Python team with a python plugin will only be slightly less, so I don't
>think this is a really great argument for writing something from
>Scratch.

This is a reasonable argument and was looked at as a first measure. But it
doesn¹t solve a lot of the issues that are seen with Gerrit because we
would still be limited to what Gerrit plugins can do and the minimal set
of triggers it currently supports.

Would the time be better spent writing addons like this to Gerrit which
would be little more then hacks to work around where we see short comings
or issues, or spend that time working on something that would be built
from the ground up to solve the issues as we see fit? I personally think
the time would be better spent working on a solution that solves our
issues and workflow better.

>Storyboard is not a good example of a reason to do this. Storyboard
>is coming from a place where there really isn't a tool that will meet
>the needs of OpenStack's processes. Launchpad is already written in
>Python, but we are not going to fix/extend it because it is an extremely
>monolithic code base and we're not really interested in rewriting it to
>be lean.
>
>To my mind, Gerrit is doing its job well, and we'd just like to make
>some incremental improvements.

>From how I see it and after many discussions with members of the Infra
team, I would see Gerrit in the same boat as launchpad. It is a monolithic
application with developers that are not versed with the structure/design.

The Storyboard project came to life for a need to have a system that meets
the OpenStack project needs better then Launchpad does. I have proposed
Vinz due to the same type of need. Gerrit works for our needs just as much
as launchpad worked for our needs 2+ years ago. It can continue to meet
our base needs, but as we grow and more external test systems are added
internal and external to infra, when is living with the shoehorned form
into our workflow no longer enough.

The whole point to this proposal is to beat the day that Gerrit won¹t fit
our workflow easily by having something ready that will be easier for us
to maintain and modify.

>Please please, even if you go through, do not integrate tightly with
>Storyboard. Use the API it provides, drive the API development, and keep
>them modular so that we can improve them at different paces.

The idea¹s for integration are purely through API. Integrating beyond that
will cause more headaches they benefits it might create.

- Philip Schwartz