Changes to our Git infrastructure
jkt at kde.org
Tue Jan 6 11:48:41 GMT 2015
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 .
So we need another approach (or tool) to help us perform review of the
architecture of our software. Got some suggestions? Launchpad blueprints?
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
More information about the kde-core-devel