And IMHO deleting branches upstream is just bad practice. From a
Yocto/OE perspective I have to consider that people might want to build
stuff in 5yrs or even 10yrs from now.
a more reasonable pattern would be to branch off from master to main,
make main the new default but leave master untouched.
But this hard renaming of branches causes headaches when maintaining layers.
Also I'd like to point out that there are plenty of examples where it's
just not the master>main transition, but projects deleting whole release
branches without a trace - so for me these extra security measures do
make sense and are really welcome.
On 13.05.21 21:36, Alexander Kanavin wrote:
On Thu, 13 May 2021 at 21:25, Benjamin Gilbert <bgilb...@backtick.net
<mailto:bgilb...@backtick.net>> wrote:
Deleting the branch normally affects people who are in the project's
developer community and pay attention to its announcements. Those
folks can then simply update their local checkouts and move on with
their lives. Everyone else just clones the default branch and maybe
checks out a particular tag or commit before building a package.
That workflow still works after the default branch is renamed.
Bitbake's additional checks are unusual, and impose a long-term
compatibility constraint on upstream projects that they didn't sign
up for.
They're not useless though. As a layer maintainer I absolutely want
those checks, as I want to be aware of any branch configuration changes
upstream, and to ensure I'm not accepting a change in source revision
that points to an unattached commit, or one from a branch that's not
supposed to be used at all.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151721):
https://lists.openembedded.org/g/openembedded-core/message/151721
Mute This Topic: https://lists.openembedded.org/mt/82782995/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
