Re: [PATCH] Add support for ccache builds with the SDK

[Paul Barker <paul@paulbarker.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 3243 bytes --]

On Tue, Sep 02, 2014 at 08:11:05AM +0100, Richard Purdie wrote:
> On Tue, 2014-09-02 at 09:22 +0300, Fathi Boudra wrote:
> > On 1 September 2014 21:04, Otavio Salvador <otavio@ossystems.com.br> wrote:
> > > Laszlo,
> > >
> > > On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp <lpapp@kde.org> wrote:
> > >> Just in case the severity is not clear. Without this change, the Yocto
> > >> SDK breaks the build for our software since we do prefer to use ccache
> > >> for speeding the build process up. We are probably not alone with that
> > >> ...
> > >
> > > Saul request is very valid. He is asking you to conform to the commit
> > > guidelines we use and it is no-sense you to expect that he or someone
> > > else does this for you.
> > >
> > > So I think if you expect this to be merged you need to fix and send a v2.
> > 
> > fwiw, we've been hit by this maintainers behavior. Several patches are
> > stuck in the queue after 10 days of non-activity, followed up by a
> > nitpick comment.
> > It's a source of frustration for the submitter and is killing his
> > motivation. Such comment could come earlier, while he's in the heat of
> > the action and he's usually more receptive to the review.
> > 
> > As a result, we lose a contribution. The
> > project/maintainer/submitter/end-user doesn't benefit from the
> > contribution.
> > 
> > my 2cts.
> 
> There are two sides to this. There can be frustrations on the submitters
> side, equally, we don't have that many people prepared to review other
> people's code. Code review is a pretty thankless task (as this thread is
> showing) and trying to pull together all the different patches, testing
> them and ensuring there are no regressions takes significant time and
> effort.
> 

Obvious style issues as this patch had don't require someone to be an expert on
the area of the code that has been changed in order to give a review. I'm happy
to keep my eyes open and try to comment where something doesn't match the patch
guidelines and a few more people doing that would catch the low hanging fruit at
least.

> 
> The kernel gets around this by having subsystem maintainers. With
> OE-Core, its certainly true that particular contributors do have
> "ownership" of parts of the system in my mind and their changes to those
> parts of the system are easier to review and accept. It would be good to
> see more of that kind of ownership too but that trust takes time to
> develop and its not something many are willing to work on. The layers
> model obviously tries to help that too.
> 

Ownership like this is excellent. What would help the most is a simple tool or
method to tell you who to Cc on a patch when you send it to the mailing list.
Linux has the "get_maintainer.pl" script for this. I haven't seen anything
similar in oe-core.

For example, I'd like to be Cc'd on changes to opkg in oe-core and vim in
meta-oe as I know those recipes well. I wouldn't expect people to wait for my
review, but a Cc might speed things up. I often miss patches to the areas I'm
interested in if I'm too busy to follow the mailing lists in detail.

Thanks,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

[-- Attachment #2: Type: application/pgp-signature, Size: 484 bytes --]