On Sun, Aug 19, 2012 at 7:03 AM, Harald Welte <laforge@xxxxxxxxxxxx> wrote:
> Hi all,
>
> I understand that different FOSS projects have different cultures,
> norms, rules, etc. However, my experience with wireshark it has reached
> a point where I think a post like this is requierd.
>
> I don't want to see this as some kind of flame, or to claim that the
> wireshark development model is bad. I just really don't understand it,
> coming from a different background. Please help me understand it.
>
> In other large projects (let's say the Linux kernel), it is customary
> that the original author of code (or a designated maintainer who has
> taken over that particular module) is always Cc'ed before a change to
> his code is being made.
>
> In wireshark, it has happened repeatedly, that code contributed by
> Osmocom developers (like the GMR dissector of Sylvain Munaut, or my
> GSMTAP dissector) has been modified erroneously (and thus broken)
> without any notice to us.
>
> I find this at least disturbing (if not annoying) adn am wondering what
> is the benefit of this practise to wireshark or its users?
>
> It is generally a fair assumption to make that somebody who writes a
> particular dissector actually cares about that code being functional,
> and that he probably knows the respective protocol quite well. In most
> caess, I would expect that author to be able to review changes to his
> code.
>
> So why are those authors not Cc'ed in any kind of patches, or merge
> requests to their code? If you don't want to wait for their explicit
> approval for efficiency reasons, you could at least notify them that
> there was a change to their code that they should review.
>
> The current situation ends up like this:
>
> * People like me who just contribute particular dissectors have no time
> to go through all of the committlog or read all of the mailing list.
>
> * Somebody else quietly makes a change, without discussing the change
> beforehand, without Cc'ing the proposed change to us
>
> * A wireshark developer committs that patch, again without Cc'ing the
> original author
>
> * Wireshark ends up being broken for the given protocol
>
> * This is not discovered for a long time, until one of the few 'bleedign
> edge' users of those protocols discovers a problem and finds the time
> to report it, at which point we get the complaint about something not
> working and have to go back in history.
>
> I would like to raise the following questions:
>
> 1) Is this the way how the wireshark development model / flow is
> supposed to work ?
>
> 2) If yes, do you really think that the gain in flexibilty caused by
> this anarchy overweighs the benefit of having dissector-authors give
> timely feedback to proposed changes, or prevent breakage?
>
> 3) Do you have any idea how to improve this situation?
>
> 4) How do other wireshark dissector authors deal with this problem?
>
> Thanks in advance!
>
> Regards,
> Harald
Hi Harald,
I've not been involved with Wireshark development for very long now,
but there are a few things that I expect are contributing to this
problem.
Mainly, there's no automated method for sending out those emails.
Wireshark code tends to see a lot of churn both in minor improvements,
bugfixes, and architectural changes. Requiring developers to send out
emails for each change would add a lot of overhead to the workflow. We
have enough trouble keeping up with bug reports as it is.
Also, while your assumption that the original author cares is probably
true in a lot of cases, it's not true in all of them, and getting
regular emails for the rest of your dissector's life could be very
spammy/annoying to some people.
I do agree that it would be a good thing if original authors could be
notified if they wanted to be. Perhaps it would be possible to add a
special 'watch' line (like the $Id$ line) to the comment header, and
have an SVN post-commit hook that sends an email to all the addresses
listed in that watch line for each changed file? Then dissector
authors can watch their own files (and any others they care about) and
they'll automatically receive a notification when those files change.
Hope this provides some explanation,
Evan
