Differential e-mail subject re-arrangement

Ben Cooksley bcooksley at kde.org
Thu Mar 2 08:08:25 UTC 2017


On Thu, Mar 2, 2017 at 10:08 AM, Dominik Haumann <dhaumann at kde.org> wrote:
> Hi,

Hi all,

>
> On Wed, Mar 1, 2017 at 4:16 PM, David Faure <faure at kde.org> wrote:
>> On mercredi 1 mars 2017 13:35:47 CET Kevin Funk wrote:
>>> On Tuesday, 28 February 2017 21:31:44 CET Michael Pyne wrote:
>>> > On Tue, Feb 28, 2017 at 08:38:12PM +0100, Ivan Čukić wrote:
>>> > > >   [Differential] D4508: Plasma controls based on QtQuickControls2
>>> > > >   [Commented On]> >
>>> > > >
>>> > > > I personally find that having a "vertical" line in which all the
>>> > > > subjects of the differential emails start makes it much easier to
>>> > > > read.>
>>> > >
>>> > > +1 I'd even shorten The 'Differential' part of it to just 'Diff'.
>>> >
>>> > Agreed to both.
>>>
>>> +1
>>
>> Yes, totally, and I would even like the repo name to be added...
>>
>> But....
>>
>> https://secure.phabricator.com/D9342 "Make Differential email subject more
>> configurable.", ABANDONED.
>>
>> https://secure.phabricator.com/T5244 "Allow email subjects and bodies to be
>> more customizable", CLOSED, WONTFIX.
>>
>> https://secure.phabricator.com/T10283 "improve differential emails, optimizing
>> for efficiency", Open, for a year.
>>
>> and my own request, https://secure.phabricator.com/T10874, Open, for almost a
>> year.
>>
>> Why did we pick a tool where upstream consistently refuses to make any changes
>> that would actually make sense? :(
>>
>> (see also https://phabricator.kde.org/T5437, "arcanist: option to ignore
>> untracked files")

I'd like to start by pointing out the following document which
upstream works by for functionality changes:
https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Note that T5244 being rejected is completely understandable from a
functionality point of view. For the record, Reviewboard is the same
in this manner (it doesn't permit mail customisation from the Admin
interface either, it requires code changes).

In regards to the way email subjects are treated, I've now customised
the metamta.differential.subject-prefix preference on our installation
to be blank, to the "[Differential]" part should no longer be present.

I have also changed the default for metamta.vary-subjects, which is a
per user setting. Anyone who likes the line count changed indicators
should open https://phabricator.kde.org/settings/, Open Email Format,
and change "Vary Subjects" to Enabled.

>
> This is unfortunate: I have the *feeling* that the automatically
> generated mails contain a lot of noise. I would appreciated to reduce
> the contents to a minimum. For instance, imo the commit mails on
> kde-commits are just perfect.
>
> With respect to the Differential subjects, I would prefer:
> [ktexteditor] D1234: Change this and that... bla bla
>
> Currently, the string "[Differential]" is 100% noise, it provides zero
> information, since the D1234 already tells me this is a patch.
> Also, I don't need any "[Updated]", or "[Request, 56 lines]" in the subject.
>
> Similarly, since the repository is ideally already in the subject, I
> don't want this to be bold and big again stretched over 3 lines in the
> email contents. The same holds for the branch, it should be in the
> subject, e.g. [ktexteditor/some_branch_name].
>
> Reviewboard was much better here.
>
> KDE is traditionally always very strong technically. We need to keep
> this strength also in our infrastructure: Provide exactly the info
> that is required, up to the point, and not more. This is essential to
> getting work done quickly. The Phab generated mails are step backward
> here, imho :-) Would be awesome if this could be improved.

We'd need a strong use case to explain to upstream why repository
should be in the Subject, and then removed from the Email.
The above is mostly (from what I can tell at least) a case of personal
preference, so isn't something we'll be able to get upstream support
for.

>
> Best regards,
> Dominik

Regards,
Ben


More information about the Kde-frameworks-devel mailing list