["Sake Blok" <sake@xxxxxxxxxx>]

Hi,

Although I don't consider myself a wireshark-developer yet (I only commited 
a couple of small patches yet), I did however experience the feelings that 
arise when the patch you sent in to the mailing-list doesn't get 
acknowledged. With my recent patch, I thought it was overlooked, but it 
turned out that a commiter had already been looking at it, but did not find 
the time to complete the review yet. This is very understandable, since 
every one is a volunteer. I do agree with Jaap that making commiters 
responsible for things will in the end have the effect that people stop 
doing work as a commiter because it conflicts with other parts of their 
life. Since I have joined wireshark-dev (~1-2 years), I have not seen many 
patches being overlooked actually. There were the occasions where a review 
lasted a little longer, but most patches were commited within a couple of 
days. Maybe a patch-tracking system is a little overkill. The majority of 
patches seem to be easy to review and commit. Some have more impact and take 
a little longer to review. If the commiter that is reviewing a patch that 
takes some time to review could send a little note to wireshark-dev that the 
patch is being reviewed, it would solve most of the issues that were 
mentioned in this thread.

Just a note on the side: Wireshark is the first OSS-project that I actually 
contribute to. First of all because I use the software on a daily basis. But 
also because I think that the wireshark community is very open and warm 
towards anyone who is seeking help in using the software or making 
contributions to it. Let's stay with this informal format, cause I think it 
works great.

Just my $0,02


Sake

----- Original Message ----- 
From: "Sebastien Tandel" <sebastien@xxxxxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sunday, March 11, 2007 7:00 PM
Subject: Re: [Wireshark-dev] Query on status of patches


> 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
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev