Gerrit mails, from address, verbosity, etc

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Jun 2 17:46:08 UTC 2016


Hi Pablo,

On Thu, Jun 02, 2016 at 07:28:35PM +0200, Pablo Neira Ayuso wrote:
> I would be pretty much supporting a different list for all these
> automated emails. Or is there a way Gerrit can interact better with
> email by restoring the previous workflow?

Same concerns here.  So make that "+2" for all gerrit mails on
separate list.

> I follow the mailing list from time to time, whenver I have some spare
> time, to follow track of what others are working on. My feeling is
> that this is not helping me.

indeed, that was triggering my initial mail on this thread.

> Are you really getting a plus with this new tool? What is in your
> opinion what really improves in your workflow since you use Gerrit?

I was very skeptical in the beginning, but from the maintainer point of
view it is actually extremely useful.  So I would recommend you give it
a try from the point of "let's keep track of patches from various
contributors, review them, provide feedback and eventually merge them"
point of view.

Comparing it to patchwork feels like comparing w3m to firefox ;)

Some plus points:
* you can immediately and automatically see who has reviewed and voted
  on each change (as opposed to manually collected "Acked-by" or the
  like)
* when subsequent versions of a patch are submitted, you can easily see
  the diff between the previous (or any previous) version and the
  current version, with change requests (comments) interspersed into the
  diff, so you can see directly if your requests have been incorporated
  in the later version
* all the review from all people is gathered in context of the
  particular code line / code lines, rather than spread over multiple
  diferent mails (one per reviwer) in an e-mail thread.
* changes run through jenkins (build test, make check, make distcheck,
  or whatever tests you have there) automatically and are not eligible
  for merge if they cause such failures. This avoids merging patches
  only to discover immediately afterwards that they don't build or don't
  pass

So I would really love to keep the above benefits.

> I just have concerns that this may just kill the little community we
> have?

The many mails to the regular mailing lits: Yes, I really see the danger
of this.  But once those are a be on a separate list, that aspect
doesn't matter anymore.

Yes, every submitter needs to do some configuration before sending in a
patch.  But then, we're not the only software project that uses gerrit,
so it's not an unusually high barrier.  And then, the number of
contributors is relatively small, so we can help them with the setup, if
needed.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list