Hi, On Tue, 26 Sep 2023 at 12:28, Maxim Cournoyer <maxim.courno...@gmail.com> wrote:
>> My understanding is that feature-branches are now the canonical way to >> work on things, and core-updates has become just another kind of >> feature-branch for landing groups of large changes that don't really >> fit anywhere; the difference being that it's now more ephemeral and >> "as needed" instead of the default for large changes. >> >> Do I have that right? >> >> I guess we need to update the manual? > > I think that's right! It misses a branch for collecting changes with large impact, for instance the ones as sed, grep, ed, etc. Somehow packages that are considered as ’core’ but are not part of another team. Right? Well, from my understanding and for one example, the update of the package Python is managed by the branch python-team but the update of package sed is managed by the branch <??>. I thought this branch <??> is still named core-updates. Well, it could also be staging. Or any other fancy name fitting the feature-branches. :-) IMHO, there is a set of packages that cannot be pushed directly to master and that do not belong to any team. Where are they pushed? And how do we check all is fine with CI/QA before landing them in master? We can create a team (base team?) for that and a dedicated branch (base-team?). IMHO, the easiest was to still consider a core-updates branch collecting changes with large impact and not part of any team; somehow a default branch for these sort of changes. I do not know. Note: it is not related to the core team. :-) It could be but, to my knowledge, it has not been discussed. Cheers, simon
