Hi Andreas and thanks for taking the notes during the discussion!

I think what came out of that discussion was very interesting and that
it would greatly help the scaling problems Guix is facing as well as
maintainer/contributor burnout, but that also means that we need to
create some actionnable plan out of it.  The window before the eventual
core-updates merge would be the best time for it, IMO!

For that plan to materialize, the best would be to agree on 1) what we
want the new workflow to be, and 2) how to get there. To start the
discussion, here's what I got out of the discussion (and is probably
opinionated):


The envisioned goal state would be to stop relying on
staging/core-updates to manage non-trivial changes to Guix, but rather
have specific branches that could be merged way faster, because they are
focused on specific features that people can feel responsible for,
instead of a hodgepodge of unrelated patches that no one wants to
debug. These feature branches would be managed by teams, with one person
from the team being responsible for the feature and it getting merged
into master. Those features could be ephemeral or long-running and each
team would be free to organize around them as they see fit, since e.g. a
Stack upgrade is very different from a Mesa upgrade, or a
gnu-build-system change.

With the improved CI/QA we have now, we shouldn't have to worry too much
since substitutes will be available right away (we should weigh what's
acceptable for people using --no-substitutes vs. keeping software more
up-to-date though, but my opinion is that in favor of the latter).

Teams should thus better document how they work and what they do, either
in the Guix documentation or a specific wiki/manual that would be
maintained by team members themselves. Having all information in one
place would help outsiders find their way around the inner workings of
the project. Maintaining roadmaps for each team, with who's working on
them and where that work can be found would also lure unsuspecting
bystanders into working on Guix features, as well as structure the
future of Guix; it shouldn't be too codified though, since we don't want
to further burden precious team members. One nice thing about
documenting all of this using a manual is that the changes go through
the guix-patches ML, so that they can be discussed and recorded for the
public to see.

Note that this change would also mean that contributors are no longer
responsible for gauging whether a patch belongs on master/staging/c-u,
but rather the reviewer/committer.  Also, as a nice side-effect of the
change, I can see people getting interested in joining teams because
they structure longer-term effort that's put into Guix, not just because
they've been maintaining python-foo-for-bar for 5 years against their
will.

Regarding releases: a release team would have to keep in touch with what
the other teams are doing, make some sort of periodic status report, and
set deadlines such as feature freezes before preparing a new release.


For a potential roadmap (doesn't have to be sequential):
1. Document this workflow in the manual, in a dedicated node, with a
   rationale as well.  One thing worth mentioning would be how to handle
   grafting/ungrafting now.  Also remove the staging/core-updates
   criterion.
2. Teams start organizing around the features they are currently working
   on, and document them accordingly. They can also draft how they work,
   what they do and their roadmap if they wish.
3. CI/QA gets examined and updated to support the new workflow. We test
   it out with a sample feature.
4. staging merge happens, and the branch gets deleted.
5. core-updates merge happens, and the branch gets deleted or
   repurposed (up to the core team).


I bet I forgot a bunch of things, but at least we get the ball rolling!

WDYT?

NB: Just noticed there is no tooling/infrastructure team, this would
probably be a good idea, to publicize the incredible work that is being
put into all of it (mumi/cuirass/qa front page/the data service), as
well as bring in some new souls and document how they all fit together.

Best,
-- 
Josselin Poiret