I'm old we should rename "master" to "trunk". Philip

https://civs.cs.cornell.edu/ Is what we use now. Philip

Just focusing on points that are prominent to me. Comments inline. Am Mi., 15. Juli 2020 um 11:12 Uhr schrieb Richard Purdie <richard.purdie@...>: Fully agreed. One of the things I

Thanks for bringing this up and writing a summary. The OE and YP TSCs are aware of this and are starting to have discussions about it. I have also been looking at what other projects and the Linux

Review comments will likely appear when patches are submitted. On that note, I recommend we move the coding style documentation from the wiki into the oe-core git repository so that changes can

Hi Jacob, Good point. I wonder where we are on the topic of anonymous voting? I think someone was working on this for various other purposes (electing TSC members, various voting for OE

Hi Josef, Not at all, your opinion is very much appreciated! Thank you for your input. I think, as a project, we need to have a position on this, and you've contributed to the discussion in a

I post them on the yocto mailing list in plain text with formatting, or you can see them all collected here in google

Howdy! See opinions and comments inline and below. Am Mi., 15. Juli 2020 um 07:31 Uhr schrieb Trevor Woerner <twoerner@...>: I explicitly welcome the awareness and think we should go forward

On Jul 15, 2020, at 01:31, Trevor Woerner <twoerner@...> wrote: Is there a YP mailing list where the minutes of the YP meeting were posted? Also discussed at the June 24th, 2020 OpenEmbedded

I guess one way to answer that question would be an anonymous voting ? Jacob

Hi, As most are aware, there are efforts in many open-source/free-software communities to adjust the language that is used throughout a given project to be more inclusive. We discussed this briefly

I think we should change to not assume default and ask branch= to be explicit perhaps will avoid future issues of such implicit changes.

On 7/7/20 7:42 PM, Richard Purdie wrote: Yes, we've met the same issue twice, iso-codes: switch upstream branch master -> main libmodulemd: switch branch master -> main

<mark.hatle@...> wrote: In case an additional example of branch specifier tripping up the build when the upstream repo changes is useful, here's one: the linux-raspberrypi recipe in

One of the reasons we were enforcing this, there were people doing package updates calling a package one version and pulling the source from a completely different branch. It was making it difficult

One of the reasons which I still find useful is that switching from SRCREV in the recipe to AUTOREV does give you latest commit from the same branch where locked SRCREV was. I don't know how important

The fetcher is strict about which branch the SHA1 is on. There were good reasons we started enforcing that, I have to admit I don't remember the reasons offhand. Its that which is tripping things

On 7/7/20 6:42 AM, Richard Purdie wrote: I'm a little confused; is the old SHA1 not an ancestor of the new branch head? I would have expected the required SHA1 to be in

What about making the git fetcher default to nobranch instead of branch=master? Using a branch name made sense back in the days when projects were not deleting branches used downstream. Having a