Wireshark-dev: Re: [Wireshark-dev] Improvments for NVMeOF dissector
What would be a reasonable time to wait? A week, two weeks, a month? Long review times a problem by themselves, since I cannot move ahead. But it is not even a problem of waiting as much, as it is a problem of communication loss. Dropping a line " will review it within 3 weeks" or "cannot handle it, too busy" "or will review later" is far less problematic then ignoring the question "can you review it, please?"
I have nothing personal to gain from this. It is true that I am using wireshark for my work on NVMEoF, but if I cannot interest the community with this work, I can fork the tree locally and continue without submitting the changes. Doing this for community was an act of contibution and a hard work, but I will not impose if there is no cooperation. As I have said, I do not think recognition. If there is an interest and someone will come up to reveiew the changes, than I continue to contibute. If the attitude is "do not bother us", why should I care?
--
----------------------------------------
Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv Storage Lab IDT Lead
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
Phone: +972-3-6897318
Fax: +972-3-6897230
----------------------------------------
From: Pascal Quantin <pascal@xxxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Date: 03/21/2021 12:02 PM
Subject: [EXTERNAL] Re: [Wireshark-dev] Improvments for NVMeOF dissector
Sent by: "Wireshark-dev" <wireshark-dev-bounces@xxxxxxxxxxxxx>
Hi Constantine, If I read the review history correctly, you were asked to perform some changes that you did 2 days ago. This is not abnormal not to get any feedback in such a short period, and that does not mean the receiver lost interest but
Hi Constantine,
If I read the review history correctly, you were asked to perform some changes that you did 2 days ago. This is not abnormal not to get any feedback in such a short period, and that does not mean the receiver lost interest but simply that he is busy.
So my suggestion is to be a bit more patient as reviewers usually do their best according to the time they can give to the project. Being too pushy can give the exact opposite of what you would like. Just my two cents.
Best regards,
Pascal.
21 mars 2021 10:47:02 Constantine Gavrilov <CONSTG@xxxxxxxxxx>:
Sometime ago, I started to work on NVMEoF
dissector. I have already contributed the number of fixes and improvements
and they have already been merged.
My goal is to have a full dissection for connection establishment, management
and IO flow, and I would like to move on quickly.
The goal is to contribute back to the community. I am not seeking recognition
-- I have plenty of that in my place of work. The goal is to help and express
my gratitude to the project.
After initial changes merged, I am stuck at getting my current merge request
(#17282)reviewed.
I understand that this is a volunteer project and all people are busy.
But I do have a problem with broken line of communication. My personal
opinion is that if a core developer "picks up" the merge request
and has review comments, they shall follow up on the requested changes
that a contributor has provided. If they loose focus or interest, they
shall inform the contributor, instead of just "disappearing".
As a contributor, I can control any form of merge request assignment
or have control over who will look at the merge request.
The fact that people are busy goes both ways -- for contributors as well
as core developers. I am looking into improving my contribution experience
for NVMEoF. Perhaps there is a core developer who is willing to look at
the changes and has sufficient interest and available time to work with
me on reviewing NVMEoF dissector changes? As it stands now, I feel blocked
from contributing (just because the speed of the review and people dropping
off). I am busy and will eventually have hard choices to make...
Perhaps I can get approval to join core developers?
--
----------------------------------------
Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv Storage Lab IDT Lead
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
----------------------------------------
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.wireshark.org_lists_wireshark-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XzHrT4jzZ2lsSkPL8XE51gcxM30kcdBgWfG2QV6bUpw&m=Pm_WNGTMDJaxPl3pTqYwOTZbE8nLo6Gj17vih_olCHI&s=Ny-xFzcNeX-gmDmEJffp5ViSSqcpcwY20i-ucIZkfsM&e=
Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.wireshark.org_mailman_options_wireshark-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XzHrT4jzZ2lsSkPL8XE51gcxM30kcdBgWfG2QV6bUpw&m=Pm_WNGTMDJaxPl3pTqYwOTZbE8nLo6Gj17vih_olCHI&s=ERRL9XIUdCMm1gTsUIesNYxjrpJfQn6aofoIV_QnZSo&e=
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
- Follow-Ups:
- Re: [Wireshark-dev] Improvments for NVMeOF dissector
- From: Pascal Quantin
- Re: [Wireshark-dev] Improvments for NVMeOF dissector
- References:
- [Wireshark-dev] Improvments for NVMeOF dissector
- From: Constantine Gavrilov
- Re: [Wireshark-dev] Improvments for NVMeOF dissector
- From: Pascal Quantin
- [Wireshark-dev] Improvments for NVMeOF dissector
- Prev by Date: [Wireshark-dev] File formats that extcap programs can write
- Next by Date: Re: [Wireshark-dev] Improvments for NVMeOF dissector
- Previous by thread: Re: [Wireshark-dev] Improvments for NVMeOF dissector
- Next by thread: Re: [Wireshark-dev] Improvments for NVMeOF dissector
- Index(es):