Le Tue, 31 Jul 2018 15:15:24 +0200, Clément Lassieur <clem...@lassieur.org> a écrit :
> Hi Pjotr, > > Pjotr Prins <pjotr.publi...@thebird.nl> writes: > > > On Mon, Jul 30, 2018 at 12:58:08PM +0200, Hartmut Goebel wrote: > >> Julien Lepiller <jul...@lepiller.eu> skribis: > >> >> We wouldcreate a new branch, stable, that would be used by guix > >> >> pull. We would continue to push to master or other branches. > >> > >> +1 > > > > Alternatively guix pull should only fetch the last tagged release. > > This has the advantage some people can test it before going into the > > wider world. Essentially a mini release cycle. And it does not have > > to be every day: > > > > 1. Decide on a time point (git hash) for the next guix pull (branch > > it) > > 2. Ask some people to test it (in addition to automated testing) > > 3. When OK tag release > > 4. Guix pull starts using that > > > > A rolling guix pull is a rather bad idea for stability ;). Unlike > > the main releases I think this can be done weekly or bi-monthly. > > With your solution, it's impossible to add security fixes, whereas > it's possible to add them to a stable branch, I believe. What I proposed was to separate the "stable" branch from security fixes by using a security channel. Security fixes (grafts) would go to the security channel, while normal updates would go to master, then stable a bit latter.
