From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: yann.morin@orange.com
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 0/3 v2] support/download: enhance svn backend
Date: Sun, 6 Aug 2023 16:40:36 +0200 [thread overview]
Message-ID: <20230806164036.60d21e39@windsurf> (raw)
In-Reply-To: <cover.1690895462.git.yann.morin@orange.com>
Hello Yann,
On Tue, 1 Aug 2023 15:11:14 +0200
yann.morin@orange.com wrote:
> Yann E. MORIN (3):
> support/download: fix shellcheck errors in svn backend
> support/download: use svn credentials to retrieve revision date
> support/download: add support to exclude svn externals
I have applied the series to next. As reported on IRC, the From: field
is not correct, as it is just From: yann.morin@orange.com, while it
should be From: Yann E. MORIN <yann.morin@orange.com> to match the
Signed-off-by value. I fixed that up when applying.
Another aspect I'd like to challenge though is your decision in PATCH
3/3 to preserve the current behavior of downloading externals as the
default. We have only one package in the tree that uses SVN as far as I
can see, so it would be easy to verify if this one uses external or
not, and do the right thing.
Yes, I know this change of the default behavior could break external
packages, but we were just discussing about switching the default CMake
backend from Makefile to Ninja once all packages in the tree have been
verified: if we following the same reasoning, we should also forever
preserve Makefile as the default CMake backend to not break external
packages.
I think we need to find the right balance between preserving backward
compatibility and moving forward with "better" solutions. I believe the
chances of having people having external packages *and* packages that
use external SVN repositories are fairly slim, so I would think that
defaulting to *not* downloading the SVN externals would be an
acceptable change. We can always mention it in the migration guidelines
at
https://buildroot.org/downloads/manual/manual.html#migrating-from-ol-versions
if we want to be extra nice.
What do you think?
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2023-08-06 14:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 13:11 [Buildroot] [PATCH 0/3 v2] support/download: enhance svn backend yann.morin
2023-08-01 13:11 ` [Buildroot] [PATCH 1/3 v2] support/download: fix shellcheck errors in " yann.morin
2023-08-01 13:11 ` [Buildroot] [PATCH 2/3 v2] support/download: use svn credentials to retrieve revision date yann.morin
2023-08-01 13:11 ` [Buildroot] [PATCH 3/3 v2] support/download: add support to exclude svn externals yann.morin
2023-08-06 14:40 ` Thomas Petazzoni via buildroot [this message]
2023-08-07 6:53 ` [Buildroot] [PATCH 0/3 v2] support/download: enhance svn backend yann.morin
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=20230806164036.60d21e39@windsurf \
--to=buildroot@buildroot.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=yann.morin@orange.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox