Workflow ideas [Was: branch master updated: gnu: eudev: Use new package style.]

[Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>]

Hi Attila,

On Tue, May 30, 2023 at 12:49 PM Attila Lendvai <attila@lendvai.name> wrote:
>
> maybe with the addition of team branches a core-updates branch would be much more manageable? and it'd be easier to merge it more frequently?

I think even fewer people will feel responsible for that unloved
branch. Instead, I would change the workflow:

1. Only folks who provide substitutes or their delegates can push to
master. That would ensure the highest availability of substitutes the
project can muster. I would rename the master branch to 'ready' or
'installable'. The people I would call "the farmers".

2. All team branches have to go through core-updates. That would
strike a balance between individual and project responsibility. Like
the "Three Musketeers," it would be "all for one, and one for all" at
that point. The pressure to make the branch clean will be felt from
all parts of the project. I would also rename the core-updates branch
to 'testing'.

3. When fixes do not introduce new features, like security or
documentation patches, the authors may appeal to "the farmers" for
direct adoption, thereby sidestepping 'testing'. The farmers can
delegate that work. The delegates I would call "the polishers".

4. No more pushes to core-updates (other than reversals) after the
second Wednesday of each month.

With that workflow, I think we would merge core-updates every one to
three weeks. People can revert.

Just another goofy idea from an odd fellow.

Kind regards
Felix