On 03/17/2014 04:20 PM, Philip Schwartz wrote: > > > On 3/17/14, 3:43 PM, "Clint Byrum" <[email protected]> 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
[email protected] / [email protected]
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
