Re: Sample command line workflow with git and gerrit

[Hadriel Kaplan <hadriel.kaplan () oracle com>]

On Feb 26, 2014, at 2:31 PM, Bálint Réczey <balint () balintreczey hu> wrote:

> From my experience (giving trainings on git/gerrit and observing other
> trainers and trainees) the most efficient way of learning Git + Gerrit based
> collaboration is reading Pro Git [1] then the Gerrit intro [2] . This is what
> is suggested by our WorkFlow page [3].
>
> Other means like trying to start with incomplete, examples-based
> quick-intros gave early satisfaction and long struggling to many people
> I could observe thanks to misunderstanding or not seeing the concepts
> behind the commands.
>
> Please don't create traps for people less experienced with git/gerrit.

I think the challenge is that there're two different sets of people wireshark needs to accommodate and keep attracting: 
the core developers, vs. the rest of us who just contribute off+on (like me)... like for example just a new dissector 
or some bug fix or whatever.  For truly trivial fixes, bugzilla patch attachments might be ok. But I thought the goal 
was to get gerrit-based commits for anything more than a few dozen lines of code. (right?)

For core developers, of course you need to read the book and as learn as much as possible about git+gerrit.

For that other group of folks, we might have never used git before or at least not gerrit, or have used it in a 
different way. To require us to read a book, and the two linked pages below, and go googling for the things missing 
from all 3, is a big hurdle and barrier to getting submissions.[1]

So the problem is this happens: there's a gerrit submission, a reviewer posts some comments on it that require a new 
patch, the submitter creates a new commit (not ammend-ed) and pushes it, gerrit creates a separate review for that new 
submission, the reviewer says "why is this a new review?" and the submitter says "what do you mean?", and so on.  This 
happened just in the past week.  Or the reviewer says "why is there trailing whitespace"?  That takes time from you the 
core developer reviewers, who aren't quite getting paid by the hour. :) Plus it means you have less time to review 
other submissions, so it penalizes others too (like me!).

My goal is to try to make the submission process as error-free as practicable, in order to give you core developers 
more time to get to my submissions. Basically I'm being selfish. :)

-hadriel
[1] And don't get me wrong - I read that "book", and it's not very big/long and it's well written and clear, and I 
liked it and was glad I read it... but my guess is many folks will consider it a burden, just to submit a dissector or 
whatever, and won't go read it.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe