Wireshark-dev: [Wireshark-dev] Why are authors never Cc'ed before their code is changed?
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
--
- Harald Welte <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
