Changes to our Git infrastructure

[Jan Kundrát]

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/