Changes to our Git infrastructure

[Andrius da Costa Ribas]

Just my humble half-cent:

regarding cli-tools:
I feel very uncomfortable on needing to install php on a Windows machine
(just as if it were Mono on a Linux machine) just to send patches to review
(maybe it's just prejudice of mine, but others may refrain from it too).
I'd prefer using a compiled program with minimum dependencies (we "all" do
have a C++ compiler) than needing an extra runtime/language/framework/etc.
just for that.
Particularly I've never used RBTools, and always have sent my "git diff"
patches through the web interface, so I second what Jeff said: "We've been
looking for more friendly, better-integrated, and more usable tools for a
long time. not just for newcomers, but especially for newcomers.". If we
provide advanced cli tools, let's make an effort to make they need a very
minimal set-up.

Regarding reviews:
I don't really have a strong opinion on whether RB encourages bad reviews
or not, but a little of a cultural aspect is present. I don't find it
discouraging when someone just writes "fix your coding style" because at
least someone took the time to look at it. What I find discouraging is when
a RR gets too old having no new reviews. The main point is that we need to
make the reviews actually flow (why there are no reviews? who can we ask to
look at it again? is it still valid? is there a better approach? If there
is really no one able to review, can we define a general rule to ship or to
discard it?)

--
Andrius.

2015-01-05 20:53 GMT-02:00 Boudewijn Rempt <boud at valdyas.org>:

> I'm just trying to make clear that reviewboard is a crappy tool inciting
> people to write crappy reviews that drive people away. Apart from any other
> nonsense about cultural differences (the standard cop-out from Dutchmen and
> Germans -- I ain't rude, I'm just honest, it's cultural!), I think that
> people should read Ian's mail, with attention:
>
> "Speaking for myself, I find this a huge turnoff in the KDE world and am
> now planning to retire from KDE as soon as I can.  But then I am 76 and git
> is my 10th source-code control system since 1965-66, so I have little
> interest in mastering it.
>
> I have also found ReviewBoard utterly counter-productive this year, either
> because one writes an entry and nobody reviews it, or nobody understands
> it, or because one gets nitpicked about syntax and white space when one is
> really looking for helpful advice about how better to solve the problem at
> hand. I think I must have lost a month or two on ReviewBoard during the
> year, with very little helpful advice gained."
>
> I consider nitpick reviews harmful. If you have nothing better to do than
> nitpick, don't, and reviewboard is a tool which encourages you to do.
>
> On Mon, 5 Jan 2015, Thomas Lübking wrote:
>
>  On Montag, 5. Januar 2015 22:58:43 CEST, Boudewijn Rempt wrote:
>>
>>  For me, personally, RB's mails are even worse.
>>>
>> Ok, but that's pretty much OT, isn't?
>>
>>  (Same problem with this thread, or rather mailing list. Why the heck do
>>> I need to get two copies of every reply to a mail of mine... One is
>>> _enough_. And yes, I know about the whole reply-to-mangling-is-dangerous
>>> lunacy.)
>>>
>> You get them, because you send them. kcd is cc'd by your mails what will
>> in the end make mail clients "reply to all" rather than just to the mailing
>> list.
>>
>>
>>
>>  Reviewboard isn't limited to kde-core-devel.
>>>
>> It's not only not limited, it's not even bound to kcd.
>> The receivers depend on the groups you attach to the RR.
>>
>>
>>  And it doesn't answer my main complaint: reviewboard, by its design, is
>>>
>> made
>>
>>> to whine about whitespace, extra white at the end of lines and other
>>> one-line complaints.
>>>
>>
>> a) breaking coding style is bad style anyway. Get a better editor, don't
>> introduce tabs and trailing spaces and weird indention etc. and there'll be
>> no complains.
>>
>> b) You missed my argument.
>> MANY ppl. can give you an abstract review ("whitespace", "hot loop,
>> performs crap", "this may crash") but only VERY FEW ppl. can make a feature
>> comment.
>> If none of the latter ever shows up because the component has vacant
>> maintainance, you might oc. feel that "ppl. only nitpick", but the
>> alternative is that your patch remains entirely uncommented and if you at
>> some point just push it, you'd introduce unnecessary style breaks and bad
>> code on top of that.
>>
>>  It gives the reviewer a happy feeling of a job well-done
>>>
>> That's nonsense. It ideally maintains general code quality by "many eyes".
>> If you are in charge of a component and have fundamental comments, you
>> certainly won't restrict yourself to comment the patch on an abstract level.
>>
>>  and the submitter a cold shower.
>>>
>> Eye of the beholder?
>> It's a tasklist. Nothing more, nothing less.
>> If that scares you, you probably would not want to hear fundamental
>> concerns at all.
>>
>> There might be a cultural gap between rather "polite" ("lying") and
>> rather "direct" ("offending") societies, but that won't be fixed by any
>> communcation tool in the near future.
>>
>> Cheers,
>> Thomas
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150105/a28aed20/attachment.htm>