From: gabriel.valcazar@digi.com
To: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH 1/2] fetch/git: Handle github dropping git:// support
Date: Thu, 11 Nov 2021 04:18:01 -0800 [thread overview]
Message-ID: <30784.1636633081071526988@lists.openembedded.org> (raw)
In-Reply-To: <5b3eb5a7a03a999e37b2ac0aacf2997819c00fd2.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]
Hi Richard,
Thanks for the explanation. I fully understand the reasoning behind your decision, but I really think this issue requires specific treatment due to its nature.
Ideally, customers using our legacy products (and thus, really old versions of our Yocto distribution) would migrate to newer products running newer software, and these situations would be avoided altogether. However, we're talking about products that are already in production, with several devices in the field that require periodic updates. Maintaining outdated software, while not recommendable from several standpoints, is oftentimes a more efficient approach than migrating to something newer, especially in these cases.
Older Yocto builds are still possible for us and our customers via docker containers or virtual machines, which provide "old" environments where the builds still work, despite all of the missing fixes in bitbake/poky. Basically, rather than patching the Yocto stack to fit our environment, we adapt our environment to fit the Yocto stack - again, because several legacy customers have made the decision to depend on old Yocto versions.
Having said this, I believe GitHub's deprecation of the git protocol is a special case because, regardless of the environment you're using or how many patches you've backported so far, builds will simply stop working altogether after the plug is pulled. No matter which environment we use, this is an external factor that's going to force changes in the Yocto stack, in areas that we have little to no control over. We're going to have to fix it either way, but it would be a much smoother transition if the fix were included by the community, and it's a unique enough case to warrant it being patched in older bitbake versions (in my opinion).
Forgive me for the insistence, but I truly believe this situation requires exceptional treatment.
Best regards,
Gabriel
[-- Attachment #2: Type: text/html, Size: 1981 bytes --]
next prev parent reply other threads:[~2021-11-11 12:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <16B3BB5E65837842.31260@lists.openembedded.org>
2021-11-03 14:13 ` [bitbake-devel] [PATCH 1/2] fetch/git: Handle github dropping git:// support Richard Purdie
2021-11-09 15:40 ` gabriel.valcazar
2021-11-09 15:44 ` [bitbake-devel] " Alexander Kanavin
2021-11-09 15:47 ` Martin Jansa
2021-11-10 15:15 ` gabriel.valcazar
2021-11-11 11:03 ` [bitbake-devel] " Richard Purdie
2021-11-11 12:18 ` gabriel.valcazar [this message]
2021-11-11 12:27 ` Alexander Kanavin
[not found] <c491c84fa505853c5744defe9466302b5276e1e4.camel@linuxfoundation.org>
2021-11-11 13:24 ` gabriel.valcazar
2021-11-02 12:44 Richard Purdie
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=30784.1636633081071526988@lists.openembedded.org \
--to=gabriel.valcazar@digi.com \
--cc=bitbake-devel@lists.openembedded.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.