Re: Disruptive changes and the next LTS 3.5 - what to aim for?


Richard Purdie
 

On Tue, 2021-09-21 at 09:43 +1200, Paul Eggleton wrote:
On Friday, 10 September 2021 19:54:11 NZST Richard Purdie wrote:
Do we change the master branch to something else? I personally have a
preference for "devel" over "main" regardless of what others are doing
as it matches what it is in our case. Changing that alone is days of
work for me trying to get all our automation to deal with it.
If the master branch gets renamed, what about yocto-buildhistory,
yocto-buildstats and yocto-testresults? Would master branches or tags
get renamed as well? Is this part of the day's worth of work you
mentioned?

Would the Yocto Project enforce a renaming in all the repos they host?

What about layer-index?
All good questions. The days of work I was mentioning would cover some of
this but there is a lot to do, more than people realise.
It's not readily visible in the UI, but the layer index already has an
internal means of specifying an alternative branch name that can be set by
admins on a per layer-branch basis. I deliberately haven't exposed it as I
thought it was better that people keep things simple and just use the same
scheme as OE-Core for their branches, but the mechanism exists. We could also
fairly easily add automatic mapping in the layer index code if we choose a
standard name to replace master, as well as changing the name shown in the UI
(and change the assumptions that "master" is the main branch, there are a few
sprinkled through the code). I think even if we do nothing else we'll have to
address those assumptions as there will probably be layer maintainers who want
to change (if they have not done so already). If it's not clear, I can
volunteer to take care of this ;)

I remembered what I was missing too:

j) Convert to SPDX license names

We should really switch to using SPDX license names in the LICENSE field
directly and be able to drop the current SPDX mapping code.
This I'm not sure of. Are these mappings costing us much? AFAICT we'd only
gain a bit of code simplification at the expense of making things a little bit
harder for our users.
I'm really trying to say it is another change we could potentially make (in the
spirit of the rest of the list).

The license functions are like spaghetti and trying to fix up the tests to work
after I tried to resolve the "or-later" changes was a nightmare. I think to move
forward the code does need to be simplified and this is one way we could do that
(else every entry into license code has to run through remapping just in case).

If the remapping moves to a tool/script to help people change the license field
to SPDX format, that could help so there are ways this could move forward yet
help.

Cheers,

Richard

Join openembedded-architecture@lists.openembedded.org to automatically receive all group messages.