Changes to our Git infrastructure

[Ian Wadham]

Hello Jan,

On 06/01/2015, at 10:48 PM, Jan Kundrát wrote:
> 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.

No, the review would be suspended while a) or b) occurred.  If b) occurs, the operative
words are "offline via email or IRC" (or face-to-face if possible).  When both parties
have reached an understanding of the problem and the issues involved, the formal
review can resume.

>> The polishing (fixing nitpicks, etc.) should come *after* the stone is cut.
> 
> That's a good suggestion.

Thanks.

>> 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 might be even worse, like joining a telephone queue…  And what about Krazy?

> 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.

Thank you, Jan.  I am really glad you find it interesting.

>>> 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 quote from DOT: https://dot.kde.org/2014/06/03/ian-wadham-venerable-kde-programmer

"Q. You've gotten the applications into good shape, and are ready to hand them off. What type of person would you like to see take over? What will they get out of working on these applications?

A. I would like to see KDE set up a maintenance group and standards for "maintainability" of code. Programs that reach a reasonably good standard could then be maintained interchangeably by members of the group.

The group could be continually changing. Nobody can stay interested in such work for long. Also the group and its stock of programs would be a good source of Junior Jobs and a place for newbies to start. It would need to have some experienced members, or ready access to such people, because some bugs are too hard for trainees to solve.

This is not a new idea. It is roughly what has been happening everywhere I have worked since about 1967, when the burden of people quitting jobs and leaving behind unmaintainable, half-finished messes became intolerable for most organizations."

Albert's Gardening group is a good start in this direction.

Re "maintainability": KDE Community code is usually not good in this regard, IMHO.

As a result, I was not at all confident about my understanding of Dr Konqi and
how to patch it.  Luckily Bugzilla had quite good documentation, so *what* to
do was fairly clear.  Nevertheless, I completely missed the side-effects (re
cookies) inherent in XML RPC and kio_http.  Those side-effects are not even
visible on my platform, only on Linux.

>>  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?

Mainly by example and praise, I would say.  Plus maybe a small checklist when
clicking "Ship It".

>>  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?

Nope.  First we need to resolve that something needs to be done, decide what needs
to be done and then do something.  Then choose a tool or method (e.g. a workshop
session).

Cheers, Ian W.