* [PATCH] Add support for ccache builds with the SDK @ 2014-08-22 15:20 Laszlo Papp 2014-08-29 10:55 ` Laszlo Papp 2014-08-29 18:29 ` Saul Wold 0 siblings, 2 replies; 10+ messages in thread From: Laszlo Papp @ 2014-08-22 15:20 UTC (permalink / raw) To: openembedded-core Signed-off-by: Laszlo Papp <lpapp@kde.org> --- meta/classes/toolchain-scripts.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass index 6cc8eba..60278d6 100644 --- a/meta/classes/toolchain-scripts.bbclass +++ b/meta/classes/toolchain-scripts.bbclass @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () { EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i" done echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >> $script + echo 'export CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >> $script echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script echo 'export CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () { rm -f $script touch $script echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script + echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> $script echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script -- 2.0.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-08-22 15:20 [PATCH] Add support for ccache builds with the SDK Laszlo Papp @ 2014-08-29 10:55 ` Laszlo Papp 2014-08-29 18:29 ` Saul Wold 1 sibling, 0 replies; 10+ messages in thread From: Laszlo Papp @ 2014-08-29 10:55 UTC (permalink / raw) To: openembedded-core One week passed and there is neither feedback, nor progress. What am I doing wrong? On Fri, Aug 22, 2014 at 4:20 PM, Laszlo Papp <lpapp@kde.org> wrote: > Signed-off-by: Laszlo Papp <lpapp@kde.org> > --- > meta/classes/toolchain-scripts.bbclass | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass > index 6cc8eba..60278d6 100644 > --- a/meta/classes/toolchain-scripts.bbclass > +++ b/meta/classes/toolchain-scripts.bbclass > @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () { > EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i" > done > echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >> $script > + echo 'export CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >> $script > echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script > echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script > echo 'export CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script > @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () { > rm -f $script > touch $script > echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script > + echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script > echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> $script > echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script > echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script > -- > 2.0.4 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-08-22 15:20 [PATCH] Add support for ccache builds with the SDK Laszlo Papp 2014-08-29 10:55 ` Laszlo Papp @ 2014-08-29 18:29 ` Saul Wold 2014-09-01 17:34 ` Laszlo Papp 1 sibling, 1 reply; 10+ messages in thread From: Saul Wold @ 2014-08-29 18:29 UTC (permalink / raw) To: Laszlo Papp, openembedded-core Might be a nit, but can you please follow the Commit Guildlines at http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines The summary should include the filename or area of the fix toolchain-script: Add ... Also can you expand on the why this is needed? Thanks Sau! On 08/22/2014 08:20 AM, Laszlo Papp wrote: > Signed-off-by: Laszlo Papp <lpapp@kde.org> > --- > meta/classes/toolchain-scripts.bbclass | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass > index 6cc8eba..60278d6 100644 > --- a/meta/classes/toolchain-scripts.bbclass > +++ b/meta/classes/toolchain-scripts.bbclass > @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () { > EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i" > done > echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >> $script > + echo 'export CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >> $script > echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script > echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script > echo 'export CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script > @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () { > rm -f $script > touch $script > echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script > + echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script > echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> $script > echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script > echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-08-29 18:29 ` Saul Wold @ 2014-09-01 17:34 ` Laszlo Papp 2014-09-01 17:47 ` Laszlo Papp 0 siblings, 1 reply; 10+ messages in thread From: Laszlo Papp @ 2014-09-01 17:34 UTC (permalink / raw) To: Saul Wold; +Cc: openembedded-core It is indeed nit, and not something I wishfully spend my time with, so feel free to rewrite the commit message and integrate the ccache support. As usual, this feature is also applied in our fork, so I am fine... It is only the upstream Yocto users who may be missing features out. Having said that, thank you for your feedback. On Fri, Aug 29, 2014 at 7:29 PM, Saul Wold <sgw@linux.intel.com> wrote: > > Might be a nit, but can you please follow the Commit Guildlines at > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > > The summary should include the filename or area of the fix > > toolchain-script: Add ... > > Also can you expand on the why this is needed? > > Thanks > Sau! > > > On 08/22/2014 08:20 AM, Laszlo Papp wrote: >> >> Signed-off-by: Laszlo Papp <lpapp@kde.org> >> --- >> meta/classes/toolchain-scripts.bbclass | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/meta/classes/toolchain-scripts.bbclass >> b/meta/classes/toolchain-scripts.bbclass >> index 6cc8eba..60278d6 100644 >> --- a/meta/classes/toolchain-scripts.bbclass >> +++ b/meta/classes/toolchain-scripts.bbclass >> @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () { >> >> EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i" >> done >> echo 'export >> PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >> >> $script >> + echo 'export >> CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >> >> $script >> echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script >> echo 'export >> PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script >> echo 'export >> CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script >> @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () { >> rm -f $script >> touch $script >> echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> >> $script >> + echo 'export >> CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script >> echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> >> $script >> echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script >> echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script >> > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-09-01 17:34 ` Laszlo Papp @ 2014-09-01 17:47 ` Laszlo Papp 2014-09-01 18:04 ` Otavio Salvador 0 siblings, 1 reply; 10+ messages in thread From: Laszlo Papp @ 2014-09-01 17:47 UTC (permalink / raw) To: Saul Wold; +Cc: openembedded-core 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 ... On Mon, Sep 1, 2014 at 6:34 PM, Laszlo Papp <lpapp@kde.org> wrote: > It is indeed nit, and not something I wishfully spend my time with, so > feel free to rewrite the commit message and integrate the ccache > support. As usual, this feature is also applied in our fork, so I am > fine... It is only the upstream Yocto users who may be missing > features out. > > Having said that, thank you for your feedback. > > On Fri, Aug 29, 2014 at 7:29 PM, Saul Wold <sgw@linux.intel.com> wrote: >> >> Might be a nit, but can you please follow the Commit Guildlines at >> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines >> >> The summary should include the filename or area of the fix >> >> toolchain-script: Add ... >> >> Also can you expand on the why this is needed? >> >> Thanks >> Sau! >> >> >> On 08/22/2014 08:20 AM, Laszlo Papp wrote: >>> >>> Signed-off-by: Laszlo Papp <lpapp@kde.org> >>> --- >>> meta/classes/toolchain-scripts.bbclass | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/meta/classes/toolchain-scripts.bbclass >>> b/meta/classes/toolchain-scripts.bbclass >>> index 6cc8eba..60278d6 100644 >>> --- a/meta/classes/toolchain-scripts.bbclass >>> +++ b/meta/classes/toolchain-scripts.bbclass >>> @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () { >>> >>> EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i" >>> done >>> echo 'export >>> PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >>> >> $script >>> + echo 'export >>> CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >>> >> $script >>> echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script >>> echo 'export >>> PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script >>> echo 'export >>> CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script >>> @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () { >>> rm -f $script >>> touch $script >>> echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> >>> $script >>> + echo 'export >>> CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script >>> echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> >>> $script >>> echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script >>> echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script >>> >> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-09-01 17:47 ` Laszlo Papp @ 2014-09-01 18:04 ` Otavio Salvador 2014-09-02 6:22 ` Fathi Boudra 0 siblings, 1 reply; 10+ messages in thread From: Otavio Salvador @ 2014-09-01 18:04 UTC (permalink / raw) To: Laszlo Papp; +Cc: openembedded-core 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. Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-09-01 18:04 ` Otavio Salvador @ 2014-09-02 6:22 ` Fathi Boudra 2014-09-02 7:11 ` Richard Purdie 2014-09-09 15:02 ` Laszlo Papp 0 siblings, 2 replies; 10+ messages in thread From: Fathi Boudra @ 2014-09-02 6:22 UTC (permalink / raw) To: Otavio Salvador; +Cc: openembedded-core 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-09-02 6:22 ` Fathi Boudra @ 2014-09-02 7:11 ` Richard Purdie 2014-09-02 9:03 ` Paul Barker 2014-09-09 15:02 ` Laszlo Papp 1 sibling, 1 reply; 10+ messages in thread From: Richard Purdie @ 2014-09-02 7:11 UTC (permalink / raw) To: Fathi Boudra; +Cc: Otavio Salvador, openembedded-core 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. In this case, the commit message does not match the guidelines. It is not the reviewers responsibility to rewrite it so it does. The other big problem that we see is that once a patch hits master, the submitter considers their job done. If there are regressions found, we sometimes see a "not my problem" attitude to getting those regressions fixed. Obviously the change can be reverted but that has its own set of problems too. Personally speaking, I just do not have the time to try and do everything I'd like to do. Ideally I'd read and reply to every patch in real time with comprehensive review. For better or worse there are other demands on my time (such as writing my own patches, mentoring others and so on). This means I try and do an best effort and this applies to others doing this work too. Even my best effort leaves me working crazy hours and is actually likely having an effect on my health :(. So I do regret people are frustrated, we doing the best we can with the people available. If more people want to step up and help consolidate patches that would be great but these kind of threads aren't going to encourage it. 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. Cheers, Richard ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-09-02 7:11 ` Richard Purdie @ 2014-09-02 9:03 ` Paul Barker 0 siblings, 0 replies; 10+ messages in thread From: Paul Barker @ 2014-09-02 9:03 UTC (permalink / raw) To: Richard Purdie; +Cc: Otavio Salvador, openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add support for ccache builds with the SDK 2014-09-02 6:22 ` Fathi Boudra 2014-09-02 7:11 ` Richard Purdie @ 2014-09-09 15:02 ` Laszlo Papp 1 sibling, 0 replies; 10+ messages in thread From: Laszlo Papp @ 2014-09-09 15:02 UTC (permalink / raw) To: Fathi Boudra; +Cc: Otavio Salvador, openembedded-core On Tue, Sep 2, 2014 at 7:22 AM, Fathi Boudra <fathi.boudra@linaro.org> 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. Thanks for trying to get things done, Fathi. I appreciate it. I also understand what Richard was writing that they are busy. Sure, I am very busy, too, but not helping others to get involved easily will leave more burden on them in the long run, sadly. This is not the first time that I have to follow changes for relatively long time, and the patch in the end does not get in, even when it fails build failures for end users, like this one. The last long bikeshed was around the busybox-ntp. Since I keep patching our Yocto fork, I thought after a while, let us give it a try again with a simple thing, and it went as far as this, only after follow-ups 1-2 weeks later. It is probably needless to say, but I feel personally very difficult to get involved in the Yocto project and I am not saying it because there are cosmetic changes with my patches. That is a good level if it is just cosmetic in a newcomer's patch anyway? I am just trying to write that as someone who is working for a very small company, I do not have time for all superfluous perfectionism this project tries to follow. I appreciate, but I cannot cope with it. My highest responsibility is to get things done and ship products. That does not include cosmetic nitpicking in a small company. It might be OK for Google, Intel, Linux Foundation, etc, but this is simply not any priority when you need to work on getting proper income for your family. Why I am personally a little bit frustrated unfortunately it is not because things like this happen, but that it happens in a row. The Yocto users are still screwed for using ntp properly with busybox. That change also went to /dev/null due to some irrelevant thing. What is worse, someone even wrote me in person that it is a shame it did not get in since that person would have also needed the feature. As far as I am concerned, the Yocto project contribution is currently unsuitable for small companies and individuals whose highest responsibility is to get income, i.e. caring about sustainable features rather than nitpicks. I have been on both sides, and I can understand when someone is maximalist. It is very difficult to understand others in the state of mind; been there, done that. Anyway, I have a relatively long list of unintegrated features into Yocto by now, but this is not quite good that they are going on their own way in a fork rather than going in. As it was written in this thread, it is quite demotivating to see such nitpicks after 1-2 weeks, and then long discussions about who is doing what. I can assure you that if I had not had several changes rejected due to such nitpicks, I would have already fixed this one, but in this case, I am not doing them anymore since I do not see any willingness from the Yocto community to try to help me with getting things easily in. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-09-09 15:02 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-08-22 15:20 [PATCH] Add support for ccache builds with the SDK Laszlo Papp 2014-08-29 10:55 ` Laszlo Papp 2014-08-29 18:29 ` Saul Wold 2014-09-01 17:34 ` Laszlo Papp 2014-09-01 17:47 ` Laszlo Papp 2014-09-01 18:04 ` Otavio Salvador 2014-09-02 6:22 ` Fathi Boudra 2014-09-02 7:11 ` Richard Purdie 2014-09-02 9:03 ` Paul Barker 2014-09-09 15:02 ` Laszlo Papp
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox