On Thu, Feb 09, 2023 at 01:19:28PM +0100, Andreas Enge wrote:
> Attached are the notes of our discussion at the Guix Days concerning
> releases, branches, teams and related matters.
>
> Andreas
>
> BRANCHES
>
> Suggestion:
> - Spin off a stable branch from master with security fixes, maybe important
> backports; after 6 months, branch a new stable branch from master; this
> is almost like a release, but continued into some future.
>
> Counter-suggestion:
> - Create branches with a few patches or patchsets; in any case with
> a "semantic" description of the changes. The branches could be
> shortlived. Feature branches are one incarnation of the concept.
> - The numerical criteria for staging and core-updates is outdated:
> Even non-core packages may create an enormous number of rebuilds.
> - Negative point: There is a risk of churn, by not regrouping world-
> rebuilding changes - but two non related world rebuilding changes
> might be difficult to review.
>
> Before creating new branches, we need to clarify how the old branches
> are handled!
>
> - Smaller branches could be taken care of by dedicated persons
> responsible for pushing them forward. For instance by teams.
> - Some people already do this for a feature branch on their local
> machine for medium-sized updates (ocaml), or even on ci (haskell,
> kernel updates).
> - Branch creators should fix a goal and tentative timeline.
> - We need a mapping between branches and maintainers responsible
> for the merge. This could be a team leader, if such a role is created.
> A wiki could be used to keep track of the branches.
> - There is discussion whether we need a core-updates branch.
> Core updates concern the toolchain, build phase changes, everything
> that has big ramifications all over the system. It would be important
> to not have several "parallel" branches with related (for instance,
> but not exclusively, core-update) changes, which in fact should come
> one after the other. Either they could be collected in one branch,
> or would require coordination of branch creation (inside a team, say).
> - "Merge trains" of gitlab are mentioned, as a way of merging several
> branches at the same time.
> - Grafts can also be handled in feature branches: The graft is applied
> to master; the graft is applied to a different branch, directly followed
> by an ungrafting commit and an update of the corresponding package;
> once the branch is built it is merged back to master.
> - Minor drawback: If qa has treated a world-rebuilding patch, the
> substitutes will be available on bordeaux, but not on berlin; people
> who have installed a long time ago and not authorised bordeaux might
> be affected. If there are complaints, they can be handled on the
> mailing list.
> - Moving fast poses problems for non-x86 architectures, but the build farm
> situation has improved for aarch64 and armhf sufficiently to keep up
> with master. Handling feature branches remains an unsolved problem.
> - Currently there is a cap on qa, only patches with at most 300 dependents
> are treated. This cap could be increased. Or it could be weighed with
> the build times of the packages.
>
>
> TEAMS
>
> - Issues could be tagged more often with responsible teams, or with
> severity information (blocking bug or not).
> - Each module should be covered by a team; otherwise it would be
> difficult to get important updates through a feature branches.
On behalf of the Rust Team™¹ we'd like to check our rust source tarballs
for any hidden binaries² and to do a mass upgrade of many of the crates.
Currently there are many crates queued up in the staging branch but we'd
like to pull them out and run a rust-team branch.
As a project we haven't setup anything for starting the team-based
branches and upgrades, and the Rust Team volunteers to go first.
Although the rust team would consider adding librsvg (and
python-cryptography) to our list of packages, we'd like to not touch it
this round, to keep it "small" (as far as rust goes) as a test.
¹ Help wanted
² https://issues.guix.gnu.org/61352
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature