On Tue, Nov 19, 2013 at 11:42 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Vadim,
On Wed, Nov 20, 2013 at 4:21 AM, Vadim Bendebury (вб) vbendeb@google.com wrote:
e
On Sun, Nov 17, 2013 at 11:31 AM, Wolfgang Denk wd@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
Hello Graeme,
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.
for Christ's sake, I am not selling anything. In fact I am quite unlikely to be contributing into u-boot in the near future, as the projects I have been working on have moved away from this bootloader. This u-boot replica was set up in my spare time and is using my employer's resources which it is willing to provide for the open source community. It is not guaranteed to be available forever.
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.
To me the problem clearly is the complexity of reviewing large patches in unified diff format. I certainly understand historical reasons for using email based unidiffs, even ten years ago there were no alternatives. But now there are, all I am trying to do is to show this community that there are other ways. It is perfectly possible that these other ways do not look that appealing/convincing to the rest of the community, or the entry threshold (as in changing the process) is prohibitively high, we all can just move on.
Wolfgang et al, please let me know if you are certain that this is not necessary, I'll shut it down then, it should be possible to set it up again later if the sentiment changes.
regards, --vb
Regards,
Graeme