[U-Boot] u-boot gerrit server

[Graeme Russ]

Hi Vadim,


On Wed, Nov 20, 2013 at 4:21 AM, Vadim Bendebury (вб) <vbendeb at google.com>wrote:

> e
>
> On Sun, Nov 17, 2013 at 11:31 AM, Wolfgang Denk <wd at denx.de> wrote:
>
> Dear Wolfgang,
>
> > [snip..]
> > Maybe I'm wrong, but my understanding was that we were not primarily
> > interested in introducing better project management tools, but in
> > reducing the work load on the maintainers, making our work more
> > efficient.
> >
>
> Having worked with email based reviews and with gerrit, I would say
> that gerrit has overwhelming advantage when it comes to reviewing
> complex changes, especially when multiple patch versions are required
> due to review comments.
>
> These are the major advantages IMO:
>
>  - the side-by side display of the changes makes it easier to
> understand what is going on
>  - the entire source file is at the reviewer's disposal if he wants to
> see a larger context
>  - it is very easy to see what changed between patch versions
>  - it is easy to pull entire patch series into a local tree if one
> wants to try a change
>

Emphasising the pros and cons of this tool versus that tool is the wrong
way to go about this. This is how salespeople convince you to buy things
you don't need - 'Let me show you how good it is at doing xyx'. Before you
know it, you've bought a fancy do-da that does a million things, but you
only end up using it for the things you _need_ to do anyway, and your come
to the realisation that your old do-da did a perfectly fine job already and
you end up using it instead because it's smaller and faster.

gerrit is a great tool. I've seen it in action and I like it a lot.

BUT - what is it we NEED. Where are the bottlenecks in the existing U-Boot
workflow? Where do things fall over? What REALLY annoys you about how we do
things now?

Don't look at features of existing tools. The biggest trap you will fall
into is selecting a tool that does a whole heap of nifty stuff you never
even thought of, and you'll forget the one thing that troubles you the most.

Maybe we could put the discussion on the Wiki. Or we could add a 'Wishlist'
document to the git repo - that way we can discuss each wish on the ML
individually, add it when it's sufficiently fleshed out, and remove it when
it's implemented.

Figure out the problem first, then look for a solution.

Regards,

Graeme