Open Stack

On 03/17/2014 04:20 PM, Philip Schwartz wrote:
> 
> 
> 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.


ssh review.openstack.org gerrit ls-projects | wc -l
254

So, smaller, but I'm not sure I'd say *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.

In fairness Storyboard came to life after we got to the point of having
a substantial number of artifacts that we could no longer manipulate in
Launchpad because it would timeout on API calls 100% of the time.

>> 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.

Have you considered other open source efforts to build upon, like
phabricator? That came up on IRC a few nights ago by Ryan Lane. And it
seems like a lot of mileage could be gained from contributing to an
existing upstream, even if it's an alternative one to gerrit.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140317/8e0782b3/attachment.pgp>