On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote:
a) "I do not know anything about Dr K, but I will try and
find someone who does."
b) "Unfortunately there is nobody available any more who
knows anything about
Dr K, but I (or another suggested guy) will try to
help. How about we take this
offline via email or IRC and then you can walk us
through the problem you are
trying to fix, its significance and impact and how you
are going about fixing it…"
This has a risk of splitting the discussion about a patch into multiple
independent streams where people will have hard time keeping track of all
the results, IMHO.
The polishing (fixing nitpicks, etc.) should come *after* the stone is cut.
That's a good suggestion.
Going straight to that mode is inappropriate because it conveys the message,
"The problem you are trying to fix is unimportant to us".
Would it work for you if there was a bot which pointed out these issues to
the patch author? That way it would be obvious which part of the review is
random nitpicking which is indeed not important when one considers the
general direction of the patch, and in addition it would come from a
machine so there won't be any bad feelings about people not appreciating
the contributor's work.
No amount of new technology, neither Gerritt nor the energy of
cats confined in a
bag, can help. "There are management solutions to technical
problems, but there
are no technical solutions to management problems", as a
colleague of mine used to say.
Agreed. So the actual problem is lack of skilled maintainers who just
aren't around. I agree that tooling cannot fix it -- the tooling can only
help by a bit by making their job easier. If the maintainer is simply not
here, then you cannot get a proper review, sure.
This is an interesting discussion, and I think that there is no problem for
it happening in parallel to the current talk about reshaping the git
infrastructure -- but maybe in another ML thread.
but the problem is that there's completely unmaintained code where
nobody feels qualified to sign off patches.
Exactly. And there are simple, technology-free solutions to that problem,
if anybody is interested.
What are these solutions?
a) There is no encouragement for the reviewer to build and TEST the
patch, independently of the reviewee.
My personal opinion is that people should not be approving patches unless
they tested them, or unless they have sufficient reason to believe that the
change is OK (such as a trivial change with an associated unit test
pre-approved by a CI run).
How can we motivate people to test these changes without discouraging them
from doing reviews at all?
c) Patching encourages incremental, "evolutionary" development,
rather than standing back and taking a "design" view of the way
things are developing. BTW, ReviewBoard supports post-commit
reviews of several patches or commits together, but that feature
is turned off in the KDE usage [1].
So we need another approach (or tool) to help us perform review of the
architecture of our software. Got some suggestions? Launchpad blueprints?
Wiki pages?
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
