From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>,
Bhaktipriya Shridhar <bhaktipriya96@gmail.com>,
kernel-janitors@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
Julia Lawall <julia.lawall@lip6.fr>,
Daniel Vetter <daniel.vetter@ffwll.ch>, Tejun Heo <tj@kernel.org>,
Thierry Reding <treding@nvidia.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: GPU-DRM-QXL: Move three assignments in qxl_device_init()
Date: Fri, 23 Sep 2016 16:23:06 +0200 [thread overview]
Message-ID: <06b207e3-88e7-8d8a-be2f-7ea7b2b7f218@users.sourceforge.net> (raw)
In-Reply-To: <CACvgo53Fc+xFeGnmmdDJJjrgmB3vA77gct4EngONuZ+Xym4_gQ@mail.gmail.com>
>> I am trying to improve various open issues also in Linux source files.
>>
> That the fact that you see issues (in these particular cases) while
> others do not
I guess that the discussed "story" affects more challenges in communication
and different opinions about where to invest software development attention.
> indicates that the commit summary could be explained better.
I imagine that there are a few improvement possibilities left over.
> A good commit summary should provide enough information to do that
This advice is generally fine.
> and make people _want_ the patch.
I guess that this expectation can become a research topic for some knowledge fields,
can't it?
There are update suggestion where the probability for acceptance is higher
than for others.
Some maintainers have got their own difficulties with changes when they categorise
them as "ordinary clean-up".
> From my limited experience through your patches (just skimmed a few)
Thanks for your general interest.
> you seems to be describing what the patch does
My collection of update suggestions is evolving over some source code search patterns.
I find that this approach fits to the recommended imperative wording style
according to document "SubmittingPatches", doesn't it?
I dared also some deviations or variations already.
> as opposed to why it does it and why should one find it interesting/wanted.
I am trying to express also this information to some degree.
Regards,
Markus
WARNING: multiple messages have this Message-ID (diff)
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>,
kernel-janitors@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
Julia Lawall <julia.lawall@lip6.fr>,
Daniel Vetter <daniel.vetter@ffwll.ch>, Tejun Heo <tj@kernel.org>,
Thierry Reding <treding@nvidia.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: GPU-DRM-QXL: Move three assignments in qxl_device_init()
Date: Fri, 23 Sep 2016 14:23:06 +0000 [thread overview]
Message-ID: <06b207e3-88e7-8d8a-be2f-7ea7b2b7f218@users.sourceforge.net> (raw)
In-Reply-To: <CACvgo53Fc+xFeGnmmdDJJjrgmB3vA77gct4EngONuZ+Xym4_gQ@mail.gmail.com>
>> I am trying to improve various open issues also in Linux source files.
>>
> That the fact that you see issues (in these particular cases) while
> others do not
I guess that the discussed "story" affects more challenges in communication
and different opinions about where to invest software development attention.
> indicates that the commit summary could be explained better.
I imagine that there are a few improvement possibilities left over.
> A good commit summary should provide enough information to do that
This advice is generally fine.
> and make people _want_ the patch.
I guess that this expectation can become a research topic for some knowledge fields,
can't it?
There are update suggestion where the probability for acceptance is higher
than for others.
Some maintainers have got their own difficulties with changes when they categorise
them as "ordinary clean-up".
> From my limited experience through your patches (just skimmed a few)
Thanks for your general interest.
> you seems to be describing what the patch does
My collection of update suggestions is evolving over some source code search patterns.
I find that this approach fits to the recommended imperative wording style
according to document "SubmittingPatches", doesn't it?
I dared also some deviations or variations already.
> as opposed to why it does it and why should one find it interesting/wanted.
I am trying to express also this information to some degree.
Regards,
Markus
WARNING: multiple messages have this Message-ID (diff)
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>,
kernel-janitors@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
Julia Lawall <julia.lawall@lip6.fr>,
Daniel Vetter <daniel.vetter@ffwll.ch>, Tejun Heo <tj@kernel.org>,
Thierry Reding <treding@nvidia.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: GPU-DRM-QXL: Move three assignments in qxl_device_init()
Date: Fri, 23 Sep 2016 16:23:06 +0200 [thread overview]
Message-ID: <06b207e3-88e7-8d8a-be2f-7ea7b2b7f218@users.sourceforge.net> (raw)
In-Reply-To: <CACvgo53Fc+xFeGnmmdDJJjrgmB3vA77gct4EngONuZ+Xym4_gQ@mail.gmail.com>
>> I am trying to improve various open issues also in Linux source files.
>>
> That the fact that you see issues (in these particular cases) while
> others do not
I guess that the discussed "story" affects more challenges in communication
and different opinions about where to invest software development attention.
> indicates that the commit summary could be explained better.
I imagine that there are a few improvement possibilities left over.
> A good commit summary should provide enough information to do that
This advice is generally fine.
> and make people _want_ the patch.
I guess that this expectation can become a research topic for some knowledge fields,
can't it?
There are update suggestion where the probability for acceptance is higher
than for others.
Some maintainers have got their own difficulties with changes when they categorise
them as "ordinary clean-up".
> From my limited experience through your patches (just skimmed a few)
Thanks for your general interest.
> you seems to be describing what the patch does
My collection of update suggestions is evolving over some source code search patterns.
I find that this approach fits to the recommended imperative wording style
according to document "SubmittingPatches", doesn't it?
I dared also some deviations or variations already.
> as opposed to why it does it and why should one find it interesting/wanted.
I am trying to express also this information to some degree.
Regards,
Markus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-09-23 14:23 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-22 6:18 [PATCH 0/4] GPU-DRM-QXL: Fine-tuning for three function implementations SF Markus Elfring
2016-09-22 6:18 ` SF Markus Elfring
2016-09-22 6:20 ` [PATCH 1/4] GPU-DRM-QXL: Use kmalloc_array() in qxl_device_init() SF Markus Elfring
2016-09-22 6:20 ` SF Markus Elfring
2016-09-22 6:21 ` [PATCH 2/4] GPU-DRM-QXL: Move three assignments " SF Markus Elfring
2016-09-22 6:21 ` SF Markus Elfring
2016-09-22 10:09 ` Dan Carpenter
2016-09-22 10:09 ` Dan Carpenter
2016-09-22 13:11 ` SF Markus Elfring
2016-09-22 13:11 ` SF Markus Elfring
2016-09-22 15:46 ` Gerd Hoffmann
2016-09-22 15:46 ` Gerd Hoffmann
2016-09-22 15:46 ` Gerd Hoffmann
2016-09-22 17:16 ` SF Markus Elfring
2016-09-22 17:16 ` SF Markus Elfring
2016-09-22 20:24 ` Gerd Hoffmann
2016-09-22 20:24 ` Gerd Hoffmann
2016-09-22 20:24 ` Dan Carpenter
2016-09-22 20:24 ` Dan Carpenter
2016-09-22 20:24 ` Dan Carpenter
2016-09-23 7:25 ` Sean Paul
2016-09-23 7:25 ` Sean Paul
2016-09-23 7:25 ` Sean Paul
2016-09-23 7:53 ` Dave Airlie
2016-09-23 7:53 ` Dave Airlie
2016-09-23 8:50 ` SF Markus Elfring
2016-09-23 8:50 ` SF Markus Elfring
2016-09-23 8:50 ` SF Markus Elfring
2016-09-23 13:30 ` Emil Velikov
2016-09-23 13:30 ` Emil Velikov
2016-09-23 14:23 ` SF Markus Elfring [this message]
2016-09-23 14:23 ` SF Markus Elfring
2016-09-23 14:23 ` SF Markus Elfring
2016-09-23 8:42 ` SF Markus Elfring
2016-09-23 8:42 ` SF Markus Elfring
2016-09-23 8:42 ` SF Markus Elfring
2016-09-23 8:34 ` SF Markus Elfring
2016-09-23 8:34 ` SF Markus Elfring
2016-09-23 8:34 ` SF Markus Elfring
2016-09-22 6:22 ` [PATCH 3/4] GPU-DRM-QXL: Improve a size determination in qxl_driver_load() SF Markus Elfring
2016-09-22 6:22 ` SF Markus Elfring
2016-09-22 6:23 ` [PATCH 4/4] GPU-DRM-QXL: Adjust checks for null pointers in three functions SF Markus Elfring
2016-09-22 6:23 ` SF Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06b207e3-88e7-8d8a-be2f-7ea7b2b7f218@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=airlied@gmail.com \
--cc=bhaktipriya96@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=treding@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.