Re: [vdsm] Patch review process
On Sun, Sep 09, 2012 at 12:27:30PM -0500, Adam Litke wrote: Hi, I want to open up a discussion about patch reviews in the vdsm project. I believe everyone will agree that more code review needs to happen for the betterment of the project. I want to ask everyone some questions and also make some observations. I hope to gain some insights and improve my own workflow. And I hope the same for everyone else too. How much time in a week do you spend reviewing patches? For me it is a couple of hours every day... We have a lot of open patches in gerrit. When deciding to review some code, how do you select a patch to review. I have heard people say that they only select patches which have named them specifically as a reviewer. How does a new contributor know who to ask? I think that `git blame` on the relevant code area would take him a long way. I personally add people I trust as reviewers to patches written by third parties. Does anyone have a workflow (or gerrit query) to select recent unreviewed patches? Are you looking for something like http://gerrit.ovirt.org/#/q/status:open+project:vdsm+-codereview%253E%253D1+-codereview%253C%253D-1+-age:1w,n,z ? I cannot say that I use anything like that. But I do search regularly for changes that have all the acks, and wait for my submitting them. While discussing gerrit recently, I learned that some people use gerrit simply to host work-in-progress patches and they don't intend for those to be reviewed. How can a reviewer recognize this and skip those patches when choosing what to review? Is there a way to mark certain patches as more important and others as drafts? Thanks for taking the time to share your thoughts. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: bootstrap: perform reboot asynchronously
* Alon Bar-Lev alo...@redhat.com [2012-09-07 15:46]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Friday, September 7, 2012 10:47:10 PM Subject: Re: Change in vdsm[master]: bootstrap: perform reboot asynchronously * Alon Bar-Lev alo...@redhat.com [2012-09-07 14:45]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Friday, September 7, 2012 10:30:18 PM Subject: Re: Change in vdsm[master]: bootstrap: perform reboot asynchronously * Alon Bar-Lev alo...@redhat.com [2012-09-05 16:11]: Alon Bar-Lev has uploaded a new change for review. Change subject: bootstrap: perform reboot asynchronously .. bootstrap: perform reboot asynchronously The use of /sbin/reboot may cause reboot to be performed at the middle of script execution. Reboot should be delayed in background so that script will have a fair chance to terminate properly. So, we fork and sleep 10 seconds? Is that really want we want to do? Why is 10 seconds enough? Shouldn't the deployUtil be tracking the script execution and waiting for the scripts to complete before rebooting? Hi, Reboot is called at the very end of the script, 10 seconds is more than enough. I don't know how we can assert that... we're not the sole process on the box. You are right that we can track the pid of the bootstrap script's parent parent parent, but it will introduce more complexity that I am not sure worth it. Why can't we just wait on the PID if it we know it? Because if we want to have this precise we need to track the following chain of processes. sshd-sh-python-python If we only track the last link in chain, it is not enough as we have race anyway, and have to wait some extra seconds, as the sh is doing some more logic and cleanups. We can create the process tree which stop either at ssh or init... but even then if this is run differently we have a problem. what's wrong with subprocess/popen and not using sh ? Do we have something that requires sh? Can we rewrite that without sh ala vdsm-tool helpers? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: Add uploadIso API call for pushing ISOs into an active iso_d...
* ih...@redhat.com ih...@redhat.com [2012-09-09 15:39]: Itamar Heim has posted comments on this change. Change subject: Add uploadIso API call for pushing ISOs into an active iso_domain via pool .. Patch Set 1: how would this work for anyone using vdsm api remotely? The wget method supports remote acquisition. -- To view, visit http://gerrit.ovirt.org/7849 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Id78e46513c38789d08e63a38026b28bebb9a2b12 Gerrit-PatchSet: 1 Gerrit-Project: vdsm Gerrit-Branch: master Gerrit-Owner: Ryan Harper ry...@us.ibm.com Gerrit-Reviewer: Federico Simoncelli fsimo...@redhat.com Gerrit-Reviewer: Itamar Heim ih...@redhat.com Gerrit-Reviewer: Ryan Harper ry...@us.ibm.com -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: Add uploadIso API call for pushing ISOs into an active iso_d...
On 09/10/2012 05:45 PM, Ryan Harper wrote: * ih...@redhat.com ih...@redhat.com [2012-09-09 15:39]: Itamar Heim has posted comments on this change. Change subject: Add uploadIso API call for pushing ISOs into an active iso_domain via pool .. Patch Set 1: how would this work for anyone using vdsm api remotely? The wget method supports remote acquisition. so how would a remote action would look like exactly? say, ovirt engine uploading the image over the api? or just a remote user - the wget would happen on vdsm rather than on the node? usually when uploading the client has the access to the image uploaded and it is passed over the api to the target? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: Add uploadIso API call for pushing ISOs into an active iso_d...
* Itamar Heim ih...@redhat.com [2012-09-10 10:08]: On 09/10/2012 05:45 PM, Ryan Harper wrote: * ih...@redhat.com ih...@redhat.com [2012-09-09 15:39]: Itamar Heim has posted comments on this change. Change subject: Add uploadIso API call for pushing ISOs into an active iso_domain via pool .. Patch Set 1: how would this work for anyone using vdsm api remotely? The wget method supports remote acquisition. so how would a remote action would look like exactly? say, ovirt engine uploading the image over the api? or just a remote user - the wget would happen on vdsm rather than on the node? usually when uploading the client has the access to the image uploaded and it is passed over the api to the target? You confuse me a bit with saying 'vdsm rather than on the node' as my understanding is that vdsm *is* on the node. Here's how I see it working, and you can tell me if I've missed something. The uploadIso takes a pool UUID which if Active and has an ISO domain, the vdsm end-point accepting the uploadIso request will have the iso domain mounted (whether or not the storage is remote or local) in which case the wget of the remote ISO write out into isoprefix location. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
* Adam Litke a...@us.ibm.com [2012-09-09 12:29]: Hi, I want to open up a discussion about patch reviews in the vdsm project. I believe everyone will agree that more code review needs to happen for the betterment of the project. I want to ask everyone some questions and also make some observations. I hope to gain some insights and improve my own workflow. And I hope the same for everyone else too. How much time in a week do you spend reviewing patches? We have a lot of open patches in gerrit. When deciding to review some code, how do you select a patch to review. I have heard people say that they only select patches which have named them specifically as a reviewer. How does a new contributor know who to ask? Does anyone have a workflow (or gerrit query) to select recent unreviewed patches? In non-gerrit communities, it's also common for patches to not get reviewed. The general approach has been to resubmit the patches to the mailing list for followup. I know in the past I've emailed this list for review requests; and that seemed to help somewhat, but I do worry that it's not obvious to developers how exactly this should be approached. If you've received some reviews (say even a +1) but are lacking the additional +1 then it seems email request is the best option since a resubmit will remove any previous reviews (+1). So, it's not clear to me what the best method (or even the preferred method of the community) is when soliciting review. I'm certainly willing to review any patches that show up on the mailing list directly, so if folks want to submit patches first for review before pushing into gerrit; I'm quite happy with reviewing those. While discussing gerrit recently, I learned that some people use gerrit simply to host work-in-progress patches and they don't intend for those to be reviewed. How can a reviewer recognize this and skip those patches when choosing what to review? Is there a way to mark certain patches as more important and others as drafts? Thanks for taking the time to share your thoughts. -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: Add uploadIso API call for pushing ISOs into an active iso_d...
* Itamar Heim ih...@redhat.com [2012-09-10 11:20]: On 09/10/2012 06:34 PM, Ryan Harper wrote: * Itamar Heim ih...@redhat.com [2012-09-10 10:08]: On 09/10/2012 05:45 PM, Ryan Harper wrote: * ih...@redhat.com ih...@redhat.com [2012-09-09 15:39]: Itamar Heim has posted comments on this change. Change subject: Add uploadIso API call for pushing ISOs into an active iso_domain via pool .. Patch Set 1: how would this work for anyone using vdsm api remotely? The wget method supports remote acquisition. so how would a remote action would look like exactly? say, ovirt engine uploading the image over the api? or just a remote user - the wget would happen on vdsm rather than on the node? usually when uploading the client has the access to the image uploaded and it is passed over the api to the target? You confuse me a bit with saying 'vdsm rather than on the node' as my understanding is that vdsm *is* on the node. indeed - s/node/client/ Here's how I see it working, and you can tell me if I've missed something. The uploadIso takes a pool UUID which if Active and has an ISO domain, the vdsm end-point accepting the uploadIso request will have the iso domain mounted (whether or not the storage is remote or local) in which case the wget of the remote ISO write out into isoprefix location. which means vdsm needs to access the iso, rather than the client. so the client can't really upload an iso which is accessible to the client this way? Client pushing in a localfile, no, but I could see about adding that if that makes this more useful. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: Add uploadIso API call for pushing ISOs into an active iso_d...
* Itamar Heim ih...@redhat.com [2012-09-10 11:33]: On 09/10/2012 07:22 PM, Ryan Harper wrote: * Itamar Heim ih...@redhat.com [2012-09-10 11:20]: On 09/10/2012 06:34 PM, Ryan Harper wrote: * Itamar Heim ih...@redhat.com [2012-09-10 10:08]: On 09/10/2012 05:45 PM, Ryan Harper wrote: * ih...@redhat.com ih...@redhat.com [2012-09-09 15:39]: Itamar Heim has posted comments on this change. Change subject: Add uploadIso API call for pushing ISOs into an active iso_domain via pool .. Patch Set 1: how would this work for anyone using vdsm api remotely? The wget method supports remote acquisition. so how would a remote action would look like exactly? say, ovirt engine uploading the image over the api? or just a remote user - the wget would happen on vdsm rather than on the node? usually when uploading the client has the access to the image uploaded and it is passed over the api to the target? You confuse me a bit with saying 'vdsm rather than on the node' as my understanding is that vdsm *is* on the node. indeed - s/node/client/ Here's how I see it working, and you can tell me if I've missed something. The uploadIso takes a pool UUID which if Active and has an ISO domain, the vdsm end-point accepting the uploadIso request will have the iso domain mounted (whether or not the storage is remote or local) in which case the wget of the remote ISO write out into isoprefix location. which means vdsm needs to access the iso, rather than the client. so the client can't really upload an iso which is accessible to the client this way? Client pushing in a localfile, no, but I could see about adding that if that makes this more useful. the main use case i see for this is an end user that wants to upload My main use-case is to work with vdsm directly; the image. users authenticate and communicate mostly with ovirt engine, not directly to hosts (they do for spice, and we will remove that via a proxy as well). any thoughts on how to solve this use case? Don't you already have engine-iso-uploader? I did see that some folks would like an in-gui method to do this, so we could address both use-cases with the same API call. In the engine UI case, you have two cases to handle: 1) user specifies an http url where the iso file is located 2) user has access on the client to an iso file she would like to push into the iso repository the uploadIso verb handles (1) right now. For (2), I see two ways: (a) engine could accept the http put from the client and store the iso temporarily on the engine server, from there push to vdsm via the uploadIso call. The advantage here would be that the client itself wouldn't need to authenticate to push data into vdsm. (b) engine could direct the client to push the iso to vdsm directly. Could be authenticated much like setVMTicket w.r.t allocating a window for the client to connect and push data. I don't see any verbs in VDSM yet where we accept lots of data via push, so this would be something we need to think about how best to handle. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
- Original Message - From: Ryan Harper ry...@us.ibm.com To: Adam Litke a...@us.ibm.com Cc: Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 10, 2012 7:07:56 PM Subject: Re: [vdsm] Patch review process * Adam Litke a...@us.ibm.com [2012-09-09 12:29]: snip I'm certainly willing to review any patches that show up on the mailing list directly, so if folks want to submit patches first for review before pushing into gerrit; I'm quite happy with reviewing those. Why won't you subscribe to vdsm-patches[1] and comment within gerrit? This method is superior as the past/present/future comments and review process is managed within productivity application, from birth to merge or death. Each comment within gerrit is going to the list as if sent directly to the mailing list, so you can track the activity. Alon. [1] https://lists.fedorahosted.org/pipermail/vdsm-patches/ ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] GlusterFS domain specific changes
On Fri, 7 Sep 2012 17:07:28 -0400 (EDT), Ayal Baron aba...@redhat.com wrote: - Original Message - As of now BD xlator supports only working with linear Logical volumes, they are thick provisioned. gluster cli command gluster volume create with option device=lv allows to work with logical volumes as files. As a POC I have a code(not posted to external list), with option device=thin to gluster volume create command it allows to work with thin provisioned targets. But it does not take care of resizing thin-pool when it reaches low-level threshold. Supporting thin targets is in our TODO list. We have dependency on lvm2 library to provide apis to create thin-targets. I'm definitely missing some background here. 1. Can the LV span on multiple bricks in gLuster? i. If 'yes' then a. do you use gLuster's replication and distribution schemes to gain performance and redundancy? b. what performance gain is there over normal gLuster with files? ii. If 'not' then you're only exposing single host local storage LVM? (in which case I don't see why gLuster is used at all and where). No, as of now BD Xlator works only with one brick. There are some issues in supporting GlusterFS features such as replication and stripe from BD xlator. We are still evaluating BD xlator for such scenarios. Advantages of BD Xlator: (*) Ease of use and unified management for both file and block based storage. (*) Making block devices available to nodes which don't have direct access to SAN. Supporting migration to nodes which don't have SAN access. (*) With FS interfaces, it becomes easier to support T10 extensions like xcopy, writesame (Currently not supported, future plan) (*) Use of dm-thin logical volumes to provide VM images that are inherently thin provisioned. It allows multi-level snapshot. When we support thin-provisioned logical volumes with 'unmap' support its almost equivalant to sparse files. This is also a future plan. From a different angle, the only benefit I can think of in exposing a fs interface over LVM is for consumers who do not wish to know the details of the underlying storage but want the performance gain of using block storage. vdsm is already intimately familiar with LVM and block devices, so adding the FS layer scheme on top doesn't strike me as adding any value. In addition, you require the consumer to know a lot about your interface because it's not truely a FS interface. e.g. consumer is not allowed to create directories, files are not sparse, not to mention that if you're indeed using LVM then I don't think you're considering the VG MD and extent size limitations: 1. LVM currently has severe limitations wrt number of objects it can manage (the limitation is actually the size of the VG metadata, but the distinction is not important just yet). This means that creating a metadata LV in addition to each data LV is very costly (at around 1000 LVs you'd hit a problem. vdsm currently creates 2 files per snapshot (the data and a small file with metadata describing it) meaning that you'd reach this limit really fast. 2. LVM max LV size is extent size * 65K, this means that if I choose a 4K extent size then my max LV size would be 256MB. This obviously won't do for VMs disks so you'd choose a much larget extent size. However a larger extent size means that each metadata file vdsm creates wastes a lot of storage space. So even if LVM could scale, your storage usage plummets and your $/MB ratio increases. The way around this is of course not to have a metadata file per volume but have 1 file containing all the metadata, but then that means I'm fully aware of the limitations of the environment and treating my objects as files gains me nothing (but does require a new hybrid domain, a lot more code etc). GlusterFS + BD xlator domain will be similar to block based storage domain. IIUC in block based storage, VSDM will not create as many LVs(files) similar to posix based storage. BD xlator provides filesystem kind of interface to create/manipulate LVs while in block based storage domain commands like lvcreate, lvextend commands are used to manipulate them. ie BD xlator provides FS interface for block based storage domain. In future when we have proper support for reflink[1] cp --reflink can be used for creating linked clone. Also there was a discussion in the past on copyfile[2] interface which could be used to create full clone of lvs [1] http://marc.info/?l=linux-fsdevelm=125296717319013w=2 [2] http://www.spinics.net/lists/linux-nfs/msg26203.html Also note that without thin provisioning we loose our ability to create snapshots. Could you please explain it? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org
Re: [vdsm] Patch review process
* Alon Bar-Lev alo...@redhat.com [2012-09-10 12:22]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Adam Litke a...@us.ibm.com Cc: Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 10, 2012 7:07:56 PM Subject: Re: [vdsm] Patch review process * Adam Litke a...@us.ibm.com [2012-09-09 12:29]: snip I'm certainly willing to review any patches that show up on the mailing list directly, so if folks want to submit patches first for review before pushing into gerrit; I'm quite happy with reviewing those. Why won't you subscribe to vdsm-patches[1] and comment within gerrit? I am subscribed. Commenting within gerrit is much slower for myself. I'm always in my email client, so sending an email back involves far less work for myself and I don't have to write lots of words in a small text box without a proper text editor. Gerrit comment workflow: 1) follow link from vdsm-patches email to gerrit patch in browser 2) sign-in via openid 3) find which patch file I want to comment upon 4) select the line I want to comment upon to bring up text widget 5) write up comment in a browswer gui box without any support from text editor 6) repeat (3-5) if there are multiple files touched 7) go back to top 8) hit publish Email comment workflow after we know have inline patches. 1) Reply to email 2) find lines in email for comments 3) write up responses in editor 4) close file and mail. This method is superior as the past/present/future comments and review I disagree here. process is managed within productivity application, from birth to merge or death. Much like an email thread with inline patches that's archived for everyone to read and review. Each comment within gerrit is going to the list as if sent directly to the mailing list, so you can track the activity. What's the point of going to the list if not to be able to respond to email? Alon. [1] https://lists.fedorahosted.org/pipermail/vdsm-patches/ -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
On 09/10/2012 08:33 PM, Ryan Harper wrote: What's the point of going to the list if not to be able to respond to email? to be able to see what's going on in bulk, in offline, via mail client. but go on gerrit to reply/discuss, or some of your comments will get lost from the patch activity. if you comment via email, other reviewers may not see your comments when they review the patch in gerrit. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
* Itamar Heim ih...@redhat.com [2012-09-10 12:43]: On 09/10/2012 08:33 PM, Ryan Harper wrote: What's the point of going to the list if not to be able to respond to email? to be able to see what's going on in bulk, in offline, via mail client. but go on gerrit to reply/discuss, or some of your comments will get lost from the patch activity. yes, I've been asking for replies to show up as gerrit comments; but I know that's not happing any time soon. if you comment via email, other reviewers may not see your comments when they review the patch in gerrit. I always cc vdsm-devel; this small group discussion of patches makes things not like a community. I like having everyone see the discussions about a patch, rather than just the reviewer. yes, I know all comments are pushed to the -patches list, but the whole point is to have code + comments + discussion in a single thread. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
* Alon Bar-Lev alo...@redhat.com [2012-09-10 12:44]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, Adam Litke a...@us.ibm.com Sent: Monday, September 10, 2012 8:33:53 PM Subject: Re: [vdsm] Patch review process * Alon Bar-Lev alo...@redhat.com [2012-09-10 12:22]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Adam Litke a...@us.ibm.com Cc: Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 10, 2012 7:07:56 PM Subject: Re: [vdsm] Patch review process * Adam Litke a...@us.ibm.com [2012-09-09 12:29]: snip I'm certainly willing to review any patches that show up on the mailing list directly, so if folks want to submit patches first for review before pushing into gerrit; I'm quite happy with reviewing those. Why won't you subscribe to vdsm-patches[1] and comment within gerrit? I am subscribed. Commenting within gerrit is much slower for myself. I'm always in my email client, so sending an email back involves far less work for myself and I don't have to write lots of words in a small text box without a proper text editor. Gerrit comment workflow: 1) follow link from vdsm-patches email to gerrit patch in browser 2) sign-in via openid 3) find which patch file I want to comment upon 4) select the line I want to comment upon to bring up text widget 5) write up comment in a browswer gui box without any support from text editor 6) repeat (3-5) if there are multiple files touched 7) go back to top 8) hit publish Email comment workflow after we know have inline patches. 1) Reply to email 2) find lines in email for comments 3) write up responses in editor 4) close file and mail. This method is superior as the past/present/future comments and review I disagree here. process is managed within productivity application, from birth to merge or death. Much like an email thread with inline patches that's archived for everyone to read and review. Each comment within gerrit is going to the list as if sent directly to the mailing list, so you can track the activity. What's the point of going to the list if not to be able to respond to email? You see the benefit of you as a reviewer, while there are other reviewers (past and future, members and guests) and there is the patch owner. While it may indeed be easier for you to just send a message, for the other people who are involved in the process it may not be as productive as managing the discussion within productivity application which supports the process quite well. Sure; There is a fixed set of folks who already have been working with gerrit for some time and I'm sure are quite comfortable with the process. Part of opening the community up is figuring out how best to attract and maintain additional developers. When growing a community, reducing the barrier for entry is a must. I'll posit that if contributions to gerrit-based communities require the additional openid, web-based commented/editing, some-what undocumented process for obtain review and approval then we're not going to see tremendous growth given the additional overhead of working with gerrit as a contributor. Only recently did we get gerrit to push the code out after submission, meaning that if someone wanted to lurk and read the code, it was always through the web-based viewing; some comments showup on the page of the changeset, the other in-line comments are only available if you know which file the comment was made against. All comments go to the vdsm-patches, but this is a one-way avenue; you don't see discussion happening in response; and if you want to reply, you have to sign-in to gerrit and hunt down the right file. None of this is *bad*; it's just different. Any one of these extra steps could be the excuse that keeps developers from participating. It is not that gerrit is perfect, it is far from being perfect, however has advantages over plain list. I'd really like to hear what advantage gerrit provides over a simple mailing list with archives and threading for developers. I'm struggling to find what problem it solves and how its use is helping grow the development community around vdsm, etc. You wrote initially that this discussion already took place, is there any new factor from previous discussion that should be taken into consideration? I don't recall exactly what you're referring to here, so point me at that comment/dicussion and I'll be happy to update/reply if things have changed since then. Regards, Alon. -- Ryan
