Wireshark-dev: Re: [Wireshark-dev] Sample command line workflow with git and gerrit
On Feb 26, 2014, at 2:31 PM, Bálint Réczey <balint@xxxxxxxxxxxxxxx> 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.
