[Sebastien Tandel <sebastien@xxxxxxxxx>]

Hi,

   I completely agree with Jaap with the view of making committers
'responsible' for different parts of wireshark.  It is not viable.
   I however don't think that's a reason to reject the idea of a patch
tracker system. I think there are some advantages, and for both sides
without imposing mandatory responsibilities for anyone :
   - Once the item is created, it is in the tracker system and won't be
lost anymore. Some patches disappear in the noise of the mailing-list
from time to time even if it is rare. Some people won't be insisting if
there is no response because the committers did not have time to take a
look at this very moment.
   - If a committer wants to review it, he may assign the task to him.
For non committing people, if the patch is not assigned to anyone, it
indicates that no one has even started to review it (which *is* a real
information for us, poor poor frustrated non committing people ;)). On
the other hand, when a committer has chosen a patch (assigned it to him)
it *should not* mean that it will be reviewed within the hour but at
least we know someone is looking at it.
   - I don't know if it happens but it may avoid double useless reviews
... Of course, any committer may review any patches even if already
assigned to another committer.


Wireshark is clearly a "community thing, not a business" but we can
anyway try to improve the way it's working for the well-being of his
community ... after all this "community thing" is not /only/ a coding
party but also a philosophical idea for the well-being of the humanity,
isn't it? :-D


Regards,
Sebastien Tandel


Jaap Keuter wrote:
> Hi,
>
> I can see your frustration. You like to be appreciated for the work done
> on creating a feature/patch you want to share with the world. That is what
> OSS is all about. On the other hand the "project owner' has to walk a
> fine line, getting enough committers in, who don't get compensation, while
> assuring quality of the work being done. This results in a varying
> response time, simple due to the fact that it's extra time the committers
> spend on this, besides their day job, familiy life, sports, etc.
> I for instance am preparing a serious telecom infrastructure overhaul in a
> major hospital, a 24 hour operation. Besides that famaily life and
> training with my sports team doesn't leave as much time as I would like to
> spend on some ideas I have for Wireshark, as well as reviewing patches.
>
> Making committers 'responsible' for different parts of the code base won't
> really work in this scenario. In the best case you'll get responses like
> "your patch is scheduled for review", after which it may take the same
> amount of time, or even longer, for the stuff to be actually looked at. In
> the worst case the committers will resign. I would, since I can't keep
> that kind of committment. For me, and most of us I think, it's a best
> effort thing.
>
> So where does that leave us? It's a community thing, not a business. That
> has all sorts of effects on the way we interact and go forward. It is not
> ideal, but neither is a business. All we can do is petition the project
> leader to get enough committers in so on the one hand the backlog won't
> get too big, while on the other hand they have enough to do. A tricky
> balance to strike.
>
> Just my $0.02
> Jaap
>
>
> On Thu, 8 Mar 2007, Richard van der Hoff wrote:
>
>   
>> Douglas Pratley wrote:
>>     
>>> I submitted two patches earlier this year:
>>> ...
>>> Can anybody tell me their current status? That is:
>>>       
>> To follow up what Doug has said, I have to say that I've found my recent
>> experiences in getting patches applied less than positive. Anders
>> applied quite a few, but there was one particular patch which I had to
>> ask _four_ times to be reviewed before anything happened. Whilst I
>> understand that everyone is busy, I'd like to give the developer's
>> perspective here and point out that it is incredibly frustrating to
>> spend a few days working on a new feature, polishing a patch and
>> submitting it, only to have it ignored. Nobody is suggesting that you
>> should apply patches without appropriate review - even a reply
>> explaining why the patch can't be reviewed right now would be something.
>> Ultimately you are only going to end up alienating your developer base,
>> which, particularly for a product like Wireshark with its millions of
>> dissectors, would be a disaster.
>>
>> Might I suggest that what is needed is a change to the procedures for
>> patch submission, review, and application. It seems to me that the
>> current problem is that no individual committer has responsibility for
>> reviewing and applying patches - so they tend to get ignored in the hope
>> that somebody else will have more time. How about if you required
>> patches to be submitted to the Bugzilla, with the responsibility for
>> different parts of the system divided amongst the committers? Then at
>> least everybody could keep track of what's on the todo list, and patches
>> wouldn't get lost in the general noise of the mailing list as I fear
>> they currently do.
>>
>> Anyway, it's not for me to tell you how to run your project, but I do
>> think it's only fair to point out that if the status quo continues, you
>> are going to end up with a lot of frustrated developers.
>>
>> Regards,
>>
>> Richard
>>
>>     
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>