Using Gerrit for libosmocore/lib../OpenBSC?
Hi, I like code-review around mailinglists (mostly everybody can read and learn from comments or code), it shows that people collaborate and that we move forward. What I don't like about the current workflow is that we need to manually close things in patchwork after applying/rejecting/ignoring a patch and that to see if it compiles and works are done after the review and by the person that applies the changes. In other projects I have used Gerrit and besides it being a Java monster found it quite okay to use. One strength is that one can directly push the changes for a branch for review, the other is that Jenkins and Gerrit can collaborate. This means that after a commit is pushed make, make check, make distcheck can be executed. Comments will always be attached to a line and not be lost due me quoting and removing parts of the mail. What I am not sure about: * How do the email notifications look like? E.g. do we just get a "Somebody has commented" mail or do we get diff + comment sent here? In OpenOCD I see there is an email with the diff[1] but no mail with the comments. * Shall we support direct pushes? I think specially in the beginning we should but the branch name for that would change. * A change that impacts libopenbsc+OpenBSC is difficult to represent. It would break "the" build but I don't see any other way. Is there enough consensus to give it a try? holger [1] http://sourceforge.net/p/openocd/mailman/message/34646766/
Hi Holger, I've never used Gerrit for real, but I assume it's similar to Github's review tools. And if so - there is one more bonus when using it - you can navigate code around the change to get more context if you're not super familiar with that place in the code. Plus highlighting really makes things easier to read than in plan text e-mails. On Thu, Nov 26, 2015 at 2:03 PM, Holger Freyther <holger@freyther.de> wrote:
Hi,
I like code-review around mailinglists (mostly everybody can read and learn from comments or code), it shows that people collaborate and that we move forward.
What I don't like about the current workflow is that we need to manually close things in patchwork after applying/rejecting/ignoring a patch and that to see if it compiles and works are done after the review and by the person that applies the changes.
In other projects I have used Gerrit and besides it being a Java monster found it quite okay to use. One strength is that one can directly push the changes for a branch for review, the other is that Jenkins and Gerrit can collaborate. This means that after a commit is pushed make, make check, make distcheck can be executed. Comments will always be attached to a line and not be lost due me quoting and removing parts of the mail.
What I am not sure about:
* How do the email notifications look like? E.g. do we just get a "Somebody has commented" mail or do we get diff + comment sent here? In OpenOCD I see there is an email with the diff[1] but no mail with the comments. * Shall we support direct pushes? I think specially in the beginning we should but the branch name for that would change. * A change that impacts libopenbsc+OpenBSC is difficult to represent. It would break "the" build but I don't see any other way.
Is there enough consensus to give it a try?
holger
[1] http://sourceforge.net/p/openocd/mailman/message/34646766/
-- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co
On Thu, Nov 26, 2015 at 12:03:04PM +0100, Holger Freyther wrote:
[Gerritt] Is there enough consensus to give it a try?
I'm neutral, if you want to try it I wouldn't object. I like simple tools like plain text mails, Gerritt seems to be the opposite. But if it helps to get the context while reading a patch and requires no further effort from us, it may well be worthwhile. My first impression is "crowded UI", but the side-by-side file view could be helpful, yes. When you say Java monster, I also think slow website. It would be nice to not have to wait too much for it to load, which in the Java world translates as "have a fast server with loads of RAM" ... please :) ~Neels -- - Neels Hofmeyr <nhofmeyr@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
On 26 Nov 2015, at 12:03, Holger Freyther <holger@freyther.de> wrote:
Hi,
Is there enough consensus to give it a try?
The alternatives (and my opinion on them) current setup - It works more scripts - Write a job that checks if pending patches "still" apply or were applied github.com - Still skeptical to rely on proprietary software to build free software gitlab.com - OpenCore so not really compatible with us reviewboard - Not good git integration (last time i checked) phabric - Used by Enlightenment/FreeBSD.. but I never understood the UI.. holger
I have never really looked at gerrit in detail, but if my understanding is correct, it requires the use of a web-based interface? I really hate web-based intefaces, as they require an online connection. The way how I read and process e-mails is store-and-forward, and I often work on them while I'm offline (in a plane, on a train, ...) It's not that I'm not particularly known for doing most of the review in recent years, but I would consider a move to mandatory use such tools as somewhat of a step of "alienation" between the project and me. It's not that the number of submissions we're getting (at least so far) is _that_ lage that it's so easy to loose track of them. Rather, there are contribuions that are not merged as a) there's not sufficient time for senior project members like Holger or me to review, or b) the original submitter is not followin up (quickly) adressing changes by the maintainer(s), or c) code that exists in some branches which is never submitted to the list in the first place I don't expect any tools to help with the issues above :/ Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
I'd like to bring up this discussion again - I think the lesser the chance for upstream to lose some contribution, the better it is. I've stumbled upon https://kallithea-scm.org/#about which does advertise code review features and in general seems like open source github. Never worked with it in real life though so I don't know if there's a catch. What do you think? cheers, Max.
participants (5)
-
Alexander Chemeris -
Harald Welte -
Holger Freyther -
Neels Hofmeyr -
☭