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 <[email protected]> wrote: > > > Laszlo, > > > > > > On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp <[email protected]> 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: [email protected] http://www.paulbarker.me.uk
pgptApIbxVG9E.pgp
Description: PGP signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
