Branch and release process (was: gnu: inetutils: Update to 2.4.)

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Leo Famulari <leo@famulari.name> writes:

> On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote:
>> Felix Lechner <felix.lechner@lease-up.com> writes:
>> > With the core-updates process now abandoned, I retitled the issue to
>> 
>> Could you share the reference of that?  I'm not against it, but our
>> currently documented process still mention the good old staging and
>> core-updates branches.
>
> At the Guix Days in February, we discussed the branching workflow and
> reached a rough consensus that for non-core packages (defined in
> %core-packages), we should try to adopt a more targeted "feature branch"
> workflow. That's actually what we used to do, before we outgrew our old
> build farm, after which we were barely able to build one branch at a
> time (IIRC, we would stop building master in order to build core-updates
> or staging).
>
> The discussion was summarized by Andreas here:
>
> https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html

Thanks!  I had missed it.  It sounds promising!

> Currently we are demo-ing this workflow in the wip-go-updates branch and
> go-team Cuirass jobset.

So the review happens first on the ML, then the changes land to the team
branch, and then finally the feature branch gets merged to master?  If
the review has already happened and the package been tested (and built
by QA), why is a feature branch needed?

> My hope is that we can rewrite the relevant documentation in the coming
> months, as we learn from these early efforts.

OK!  Thanks for allowing me to catch up!

-- 
Thanks,
Maxim