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.orgHi 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)