Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves
Date: Wed, 13 Jun 2018 11:57:05 +0200	[thread overview]
Message-ID: <20180613115705.43c5b5b3@windsurf> (raw)
In-Reply-To: <fb74bf87-dfdf-5dc6-8612-9faa896ae6e4@mind.be>

Arnout,

On Wed, 13 Jun 2018 11:47:02 +0200, Arnout Vandecappelle wrote:

> >> I didn't want to write anything to this thread at first, but then I
> >> saw that what Trent wrote matches 100% what I was thinking when
> >> looking at the change.
> >>
> >> I'm very disappointed with the attitude displayed by the buildroot
> >> developers in this thread.  
> > 
> > I believe you are also very abrupt with this statement. For example, I
> > myself asked as a reply to Yann's proposal if there wasn't a backward
> > compatibility issue.  
> 
>  Thomas, you can't deny that, whatever your (and my) intention was in this
> thread, it clearly has the effect on (some) people that they think "the
> buildroot developers" are not paying attention to their needs.
> 
>  I don't know why that is or what we can do about it (without investing still
> more time in composing our mails), but the least we can do is acknowledge this
> situation.

I will have to read this specific thread again to see what could
communicate this feeling.

However, generally speaking, I do agree that we tend to push back on
people proposing to add more complexity to Buildroot, for the reasons
I've highlighted before. And I definitely understand that such regular
push back, or sometimes slowness to take a decision on specific topics
can be frustrating. I do completely acknowledge that.

However, this push back and/or slowness on topics that suggest changing
some core aspect of Buildroot or its complexity level is actually more
a feature than a bug. It is what allows to preserve Buildroot core
principles on the long run. The contributors pushing for a little bit
more complexity here only see a little bit more complexity in one
specific place. People who have been around for a much longer period of
time (I'm "celebrating" this year my 10th year contributing to
Buildroot, and Peter has been contributing for longer than that, etc.)
have a different perspective, as they see the overall complexity
increase, not just the specific complexity increase caused by one patch.

But, yes I acknowledge that we are reluctant to change, and sometimes
need a lot of convincing arguments to change our minds.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-06-13  9:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-09 21:06 [Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves Yann E. MORIN
2018-06-09 21:16 ` Yann E. MORIN
2018-06-10  6:03 ` Thomas Petazzoni
2018-06-10  7:47   ` Yann E. MORIN
2018-06-10 21:21 ` Arnout Vandecappelle
2018-06-11 17:20   ` Trent Piepho
2018-06-11 19:01     ` Thomas Petazzoni
2018-06-11 22:10       ` Trent Piepho
2018-06-12  9:57         ` Thomas Petazzoni
2018-06-12 17:11           ` Trent Piepho
2018-06-12 13:30     ` Arnout Vandecappelle
2018-06-12 17:47       ` Trent Piepho
2018-06-12 18:07         ` Stefan Becker
2018-06-12 19:01           ` Thomas Petazzoni
2018-06-12 19:25             ` Stefan Becker
2018-06-13  8:32               ` Andreas Naumann
2018-06-13 10:12                 ` Arnout Vandecappelle
2018-06-13 15:46                   ` Andreas Naumann
2018-06-13  9:47             ` Arnout Vandecappelle
2018-06-13  9:57               ` Thomas Petazzoni [this message]
2018-06-13 10:03                 ` Stefan Becker
2018-06-13 11:58                   ` Thomas Petazzoni
2018-06-15 18:27             ` Peter Korsgaard
2018-06-13  7:46         ` Arnout Vandecappelle
2018-06-13  7:59           ` Stefan Becker
2018-06-15 18:12     ` Peter Korsgaard

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=20180613115705.43c5b5b3@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox