Ensuring we don't break user systems

Ensuring we don't break user systems

[Julien Lepiller]

Hi guix!

I recently had an idea about how we should organize ourworkflow for post 1.0. The goal is to ensure that users can always update their system.

Currently, we push updatesto master and they may not build on other architectures or break dependant packages. This is bad because a security update might get blocked because an unrelated package now fails to build.

I'd like to propose the following policy:

We wouldcreate a new branch, stable, that would be used by guix pull. We would continue to push to master or other branches.

Once hydra finds it can build at least as many packages in master than stable, it would make master the new stable, hopefully once a day or so.

Security updates would be provided to users by a seéarate channel, to ensure important updates are delivered immediately to users.

Another possibility is to use a patch management system like gerrit with a similar policy.

WDYT?

Re: Ensuring we don't break user systems

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

I like this a lot!

Security aside, I also think it's very important for 1.0 that casual users
(i.e. non-devs) can `guix pull' without rebuilding half their packages because hydra
hadn't had the time to rebuild everything from the latest commit.

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Ensuring we don't break user systems

[Dan Partelly]

Even more important than this, is that the users do not end up with a broken package manager  following a guix pull. Which is what happened pretty often in my experiences with GuixSD. Yes, yes, you can “roll-back”. The bottom line is , the system should not break in the first place. GuixSD should not inflict its development branch of the package manager on the world, and the stable branch should be regression tested

> On Jul 29, 2018, at 12:45, Pierre Neidhardt <ambrevar@gmail.com> wrote:
> 
> I like this a lot!
> 
> Security aside, I also think it's very important for 1.0 that casual users
> (i.e. non-devs) can `guix pull' without rebuilding half their packages because hydra
> hadn't had the time to rebuild everything from the latest commit.
> 
> -- 
> Pierre Neidhardt

Re: Ensuring we don't break user systems

[Dan Partelly]

I pointed this out 4-5 weeks ago when trying GuixSD, on this very list. Thanks for reaffirming  the idea In all honesty the current model is very badly broken, and you should not wait for 1.0. I had no other Linux distro break up faster than GuixSD. A stable branch is not enough by itself,  (but is the mort important part) you need to ensure that all substitutes are built correctly, and atomically update all substitutes following a successful build of all packages. 

 You should not inflict  current model on your users , not  even for an 0.1



> On Jul 29, 2018, at 12:40, Julien Lepiller <julien@lepiller.eu> wrote:
> 
> Hi guix!
> 
> I recently had an idea about how we should organize ourworkflow for post 1.0. The goal is to ensure that users can always update their system.
> 
> Currently, we push updatesto master and they may not build on other architectures or break dependant packages. This is bad because a security update might get blocked because an unrelated package now fails to build.
> 
> I'd like to propose the following policy:
> 
> We wouldcreate a new branch, stable, that would be used by guix pull. We would continue to push to master or other branches.
> 
> Once hydra finds it can build at least as many packages in master than stable, it would make master the new stable, hopefully once a day or so.
> 
> Security updates would be provided to users by a seéarate channel, to ensure important updates are delivered immediately to users.
> 
> Another possibility is to use a patch management system like gerrit with a similar policy.
> 
> WDYT?
> 

Re: Ensuring we don't break user systems

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]


Dan Partelly <dan_partelly@rdsor.ro> writes:

> I pointed this out 4-5 weeks ago when trying GuixSD, on this very list. Thanks for reaffirming  the idea In all honesty the current model is very badly broken, and you should not wait for 1.0. I had no other Linux distro break up faster than GuixSD. A stable branch is not enough by itself,  (but is the mort important part) you need to ensure that all substitutes are built correctly, and atomically update all substitutes following a successful build of all packages.
>
>  You should not inflict  current model on your users , not  even for an 0.1

While this might apply to some software. I don't believe, and I don't
think you've shown that this reasoning is appropriate or useful to apply
to Guix.

Saying that something doesn't work for you is fine, and can be helpful,
but such a unevidenced extreme view is unhelpful.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: Ensuring we don't break user systems

[Dan Partelly]

No I did not shown or proofed this affirmation. I believe it is sensible.  It is a undeniable reality of software development  that bugs are introduced during development. Having the update to the package manager (which in GuixSD is very central to the distro itself) 
result in a broken system "even if you can roll back” is a very bad thing. It is my opinion that the current model is both technically bad (exposing users to broken software , security bugs and so on) and socially bad ( having the package manager crap on itself due to bugs introduced in the development cycle may prompt a lot of people to look in to an alternative and creates bad publicity. It also results in end users wasting time, and time is the most precious comodity we have. I do not want the OS I use to waste my time. I want to install the software I need and work with and go on with my life and work  ). Ironically, the problem is easily solved . DO not expose people to your devel branch where they will get first contact wiith guix bugs and guile bugs. The situation with GuixSD is somehow complicated by the fact that the package metadata is compiled as code, but yeah, a stable branch which is proven to be compilable and preferably regression tested is the first step IMO towards a better future with GuixSD. Treat is as a product which offers a rock solid platform for the users.

And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a  lot. That is a fact, unfortunately. 
> Dan Partelly <dan_partelly@rdsor.ro> writes:
> 
>> I pointed this out 4-5 weeks ago when trying GuixSD, on this very list. Thanks for reaffirming  the idea In all honesty the current model is very badly broken, and you should not wait for 1.0. I had no other Linux distro break up faster than GuixSD. A stable branch is not enough by itself,  (but is the mort important part) you need to ensure that all substitutes are built correctly, and atomically update all substitutes following a successful build of all packages.
>> 
>> You should not inflict  current model on your users , not  even for an 0.1
> 
> While this might apply to some software. I don't believe, and I don't
> think you've shown that this reasoning is appropriate or useful to apply
> to Guix.
> 
> Saying that something doesn't work for you is fine, and can be helpful,
> but such a unevidenced extreme view is unhelpful.

Re: Ensuring we don't break user systems

[Nils Gillmann]

We just have 2 different views here.

When Guix started, which was about 3 years before I joined, the model
was okay. Between 2015 and now the amount of breakage has been
extremely reduced due to discussions about more reasonable development
models. For a while now we have an informal rfc for bigger changes -
this is a result from "please don't do that without asking first"
because some of us got upset about assuming that all changes are okay.

I sympathize with your point of view - in production even a couple of
breaking commits are bad.

We have grown over the last years, but developing reasonable deployment
models which fit our group takes time.

I'm okay with defining a branching model and use it once we have the
tooling and infrastructure for it.

Dan Partelly transcribed 2.4K bytes:
> No I did not shown or proofed this affirmation. I believe it is sensible.  It is a undeniable reality of software development  that bugs are introduced during development. Having the update to the package manager (which in GuixSD is very central to the distro itself) 
> result in a broken system "even if you can roll back” is a very bad thing. It is my opinion that the current model is both technically bad (exposing users to broken software , security bugs and so on) and socially bad ( having the package manager crap on itself due to bugs introduced in the development cycle may prompt a lot of people to look in to an alternative and creates bad publicity. It also results in end users wasting time, and time is the most precious comodity we have. I do not want the OS I use to waste my time. I want to install the software I need and work with and go on with my life and work  ). Ironically, the problem is easily solved . DO not expose people to your devel branch where they will get first contact wiith guix bugs and guile bugs. The situation with GuixSD is somehow complicated by the fact that the package metadata is compiled as code, but yeah, a stable branch which is proven to be compilable and preferably regression tested is the first step IMO towards a better future with GuixSD. Treat is as a product which offers a rock solid platform for the users.
> 
> And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a  lot. That is a fact, unfortunately. 
> > Dan Partelly <dan_partelly@rdsor.ro> writes:
> > 
> >> I pointed this out 4-5 weeks ago when trying GuixSD, on this very list. Thanks for reaffirming  the idea In all honesty the current model is very badly broken, and you should not wait for 1.0. I had no other Linux distro break up faster than GuixSD. A stable branch is not enough by itself,  (but is the mort important part) you need to ensure that all substitutes are built correctly, and atomically update all substitutes following a successful build of all packages.
> >> 
> >> You should not inflict  current model on your users , not  even for an 0.1
> > 
> > While this might apply to some software. I don't believe, and I don't
> > think you've shown that this reasoning is appropriate or useful to apply
> > to Guix.
> > 
> > Saying that something doesn't work for you is fine, and can be helpful,
> > but such a unevidenced extreme view is unhelpful.
> 
> 

Re: Ensuring we don't break user systems

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 3512 bytes --]

Le lun. 30 juil. 2018 à 23:17, Nils Gillmann <ng0@n0.is> a écrit :

> We just have 2 different views here.
>
> When Guix started, which was about 3 years before I joined, the model
> was okay. Between 2015 and now the amount of breakage has been
> extremely reduced due to discussions about more reasonable development
> models. For a while now we have an informal rfc for bigger changes -
> this is a result from "please don't do that without asking first"
> because some of us got upset about assuming that all changes are okay.
>
> I sympathize with your point of view - in production even a couple of
> breaking commits are bad.
>
> We have grown over the last years, but developing reasonable deployment
> models which fit our group takes time.
>
> I'm okay with defining a branching model and use it once we have the
> tooling and infrastructure for it.
>
> Dan Partelly transcribed 2.4K bytes:
> > No I did not shown or proofed this affirmation. I believe it is
> sensible.  It is a undeniable reality of software development  that bugs
> are introduced during development. Having the update to the package manager
> (which in GuixSD is very central to the distro itself)
> > result in a broken system "even if you can roll back” is a very bad
> thing. It is my opinion that the current model is both technically bad
> (exposing users to broken software , security bugs and so on) and socially
> bad ( having the package manager crap on itself due to bugs introduced in
> the development cycle may prompt a lot of people to look in to an
> alternative and creates bad publicity. It also results in end users wasting
> time, and time is the most precious comodity we have. I do not want the OS
> I use to waste my time. I want to install the software I need and work with
> and go on with my life and work  ). Ironically, the problem is easily
> solved . DO not expose people to your devel branch where they will get
> first contact wiith guix bugs and guile bugs. The situation with GuixSD is
> somehow complicated by the fact that the package metadata is compiled as
> code, but yeah, a stable branch which is proven to be compilable and
> preferably regression tested is the first step IMO towards a better future
> with GuixSD. Treat is as a product which offers a rock solid platform for
> the users.
> >
> > And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a  lot.
> That is a fact, unfortunately.
> > > Dan Partelly <dan_partelly@rdsor.ro> writes:
> > >
> > >> I pointed this out 4-5 weeks ago when trying GuixSD, on this very
> list. Thanks for reaffirming  the idea In all honesty the current model is
> very badly broken, and you should not wait for 1.0. I had no other Linux
> distro break up faster than GuixSD. A stable branch is not enough by
> itself,  (but is the mort important part) you need to ensure that all
> substitutes are built correctly, and atomically update all substitutes
> following a successful build of all packages.
> > >>
> > >> You should not inflict  current model on your users , not  even for
> an 0.1
>

You say there is not enough guix developpers.


> > > While this might apply to some software. I don't believe, and I don't
> > > think you've shown that this reasoning is appropriate or useful to
> apply
> > > to Guix.
> > >
> > > Saying that something doesn't work for you is fine, and can be helpful,
> > > but such a unevidenced extreme view is unhelpful.
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 4107 bytes --]

Re: Ensuring we don't break user systems

[Nils Gillmann]

Amirouche Boubekki transcribed 7.8K bytes:
> Le lun. 30 juil. 2018 à 23:17, Nils Gillmann <ng0@n0.is> a écrit :
> 
> > We just have 2 different views here.
> >
> > When Guix started, which was about 3 years before I joined, the model
> > was okay. Between 2015 and now the amount of breakage has been
> > extremely reduced due to discussions about more reasonable development
> > models. For a while now we have an informal rfc for bigger changes -
> > this is a result from "please don't do that without asking first"
> > because some of us got upset about assuming that all changes are okay.
> >
> > I sympathize with your point of view - in production even a couple of
> > breaking commits are bad.
> >
> > We have grown over the last years, but developing reasonable deployment
> > models which fit our group takes time.
> >
> > I'm okay with defining a branching model and use it once we have the
> > tooling and infrastructure for it.
> >
> > Dan Partelly transcribed 2.4K bytes:
> > > No I did not shown or proofed this affirmation. I believe it is
> > sensible.  It is a undeniable reality of software development  that bugs
> > are introduced during development. Having the update to the package manager
> > (which in GuixSD is very central to the distro itself)
> > > result in a broken system "even if you can roll back” is a very bad
> > thing. It is my opinion that the current model is both technically bad
> > (exposing users to broken software , security bugs and so on) and socially
> > bad ( having the package manager crap on itself due to bugs introduced in
> > the development cycle may prompt a lot of people to look in to an
> > alternative and creates bad publicity. It also results in end users wasting
> > time, and time is the most precious comodity we have. I do not want the OS
> > I use to waste my time. I want to install the software I need and work with
> > and go on with my life and work  ). Ironically, the problem is easily
> > solved . DO not expose people to your devel branch where they will get
> > first contact wiith guix bugs and guile bugs. The situation with GuixSD is
> > somehow complicated by the fact that the package metadata is compiled as
> > code, but yeah, a stable branch which is proven to be compilable and
> > preferably regression tested is the first step IMO towards a better future
> > with GuixSD. Treat is as a product which offers a rock solid platform for
> > the users.
> > >
> > > And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a  lot.
> > That is a fact, unfortunately.
> > > > Dan Partelly <dan_partelly@rdsor.ro> writes:
> > > >
> > > >> I pointed this out 4-5 weeks ago when trying GuixSD, on this very
> > list. Thanks for reaffirming  the idea In all honesty the current model is
> > very badly broken, and you should not wait for 1.0. I had no other Linux
> > distro break up faster than GuixSD. A stable branch is not enough by
> > itself,  (but is the mort important part) you need to ensure that all
> > substitutes are built correctly, and atomically update all substitutes
> > following a successful build of all packages.
> > > >>
> > > >> You should not inflict  current model on your users , not  even for
> > an 0.1
> >
> 
> You say there is not enough guix developpers.

Who or what exactly are you replying to?

My understanding is: We are slowly growing to the point (conmtributor
and user wise) where we have to think about the trust people put in
us, and - even when most of us work on this as volunteers - look at
our development model (or rather how users interact with it).

But maybe you meant something else..? 
> 
> > > > While this might apply to some software. I don't believe, and I don't
> > > > think you've shown that this reasoning is appropriate or useful to
> > apply
> > > > to Guix.
> > > >
> > > > Saying that something doesn't work for you is fine, and can be helpful,
> > > > but such a unevidenced extreme view is unhelpful.
> > >
> > >
> >
> >

Re: Ensuring we don't break user systems

[Dan Partelly]

[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]

It all boils down to what you desire GuixSD to become. If you want it to be a hacker playground, than any model is good. If you want it to be a reliable OS used in production some day, then, frankly, you need live up to the reliability promise you have on the distro www page, even if this means a certain degree of inconvenience to the developers and they will have to adapt their habits to the new model.  And it aint gonna be funny, but needs to be done.

I also believe that an iterative process is better than devising from a to z a deployment model , wait for complete tool development, then go through a painful transition period. Why ?

- devising a complete model and tools will take years. In this time the promise of reliability will not be fulfilled, and an already low user base will become lower as a consequence.  I have to reiterate, in the wild adoption of software has almost nothing to do with technical excellence but almost everything with social factors. People couldn't care less about whats great about GuixSd if it breaks easily. 

- you will lower the amount of bikeshedding. A full a to z change will require a lot of agreeing on new models, operations change , infrastructure work and some of the decision will be unpopular with some developers who will try to fight it. Iterations will help IMO to minimize this.

-you will lower the amount of factors you need to juggle simultaneously to ensure a smooth transition with iteration. This in effect will lower the negative effects the transition has on your own developers. 


- you will have something today,as opposed in a couple of years. Users are appreciative of  increases in reliability and they might stay interested if they see work is actively done.  Last thing users (leaving aside sticking with something on philosophical grounds )  want is to  fight the OS and solve breakages. In fact having to solve OS breakages (when you use the OS not develop it) builds negative reactions in most humans. Once a breakage is encountered at OS level (which in guixsd includes guix) inevitably the next question is “Why should I use this ? It wastes my time”. And the negative reaction is usually strong, as in - it eclipses other positive of the OS.

-stability and reliability  in themselves  much more important than features such as device mapper / lvm / root on exotic filesystems ,  whatever. 

- leaving aside social factors, even technically , inflicting a development  branch on anyone but the developers / testers is *the wrong thing to do(TM)*. 

Those , of course, are just my thoughts based on the empirical observations I made in time.  

> On Jul 31, 2018, at 00:16, Nils Gillmann <ng0@n0.is> wrote:
> 
> We have grown over the last years, but developing reasonable deployment
> models which fit our group takes time.


[-- Attachment #2: Type: text/html, Size: 4842 bytes --]

Re: Ensuring we don't break user systems

[Julien Lepiller]

Hi,

I totally agree with this view: small incremental changes are better. As a first step, I think we could implement a way for cuirass to compare builds between two jobsets, reporting the number of failed build in one jobset that succeeded in another. I think this is the technical part. Then we could encourage people to make more feature branches that would be evaluated and merged into master once cuirass reports no new failure compared to master.

Le 31 juillet 2018 08:17:58 GMT+02:00, Dan Partelly <dan_partelly@rdsor.ro> a écrit :
>It all boils down to what you desire GuixSD to become. If you want it
>to be a hacker playground, than any model is good. If you want it to be
>a reliable OS used in production some day, then, frankly, you need live
>up to the reliability promise you have on the distro www page, even if
>this means a certain degree of inconvenience to the developers and they
>will have to adapt their habits to the new model.  And it aint gonna be
>funny, but needs to be done.
>
>I also believe that an iterative process is better than devising from a
>to z a deployment model , wait for complete tool development, then go
>through a painful transition period. Why ?
>
>- devising a complete model and tools will take years. In this time the
>promise of reliability will not be fulfilled, and an already low user
>base will become lower as a consequence.  I have to reiterate, in the
>wild adoption of software has almost nothing to do with technical
>excellence but almost everything with social factors. People couldn't
>care less about whats great about GuixSd if it breaks easily. 
>
>- you will lower the amount of bikeshedding. A full a to z change will
>require a lot of agreeing on new models, operations change ,
>infrastructure work and some of the decision will be unpopular with
>some developers who will try to fight it. Iterations will help IMO to
>minimize this.
>
>-you will lower the amount of factors you need to juggle simultaneously
>to ensure a smooth transition with iteration. This in effect will lower
>the negative effects the transition has on your own developers. 
>
>
>- you will have something today,as opposed in a couple of years. Users
>are appreciative of  increases in reliability and they might stay
>interested if they see work is actively done.  Last thing users
>(leaving aside sticking with something on philosophical grounds )  want
>is to  fight the OS and solve breakages. In fact having to solve OS
>breakages (when you use the OS not develop it) builds negative
>reactions in most humans. Once a breakage is encountered at OS level
>(which in guixsd includes guix) inevitably the next question is “Why
>should I use this ? It wastes my time”. And the negative reaction is
>usually strong, as in - it eclipses other positive of the OS.
>
>-stability and reliability  in themselves  much more important than
>features such as device mapper / lvm / root on exotic filesystems , 
>whatever. 
>
>- leaving aside social factors, even technically , inflicting a
>development  branch on anyone but the developers / testers is *the
>wrong thing to do(TM)*. 
>
>Those , of course, are just my thoughts based on the empirical
>observations I made in time.  
>
>> On Jul 31, 2018, at 00:16, Nils Gillmann <ng0@n0.is> wrote:
>> 
>> We have grown over the last years, but developing reasonable
>deployment
>> models which fit our group takes time.

Re: Ensuring we don't break user systems

[Julien Lepiller]

Le Sun, 29 Jul 2018 19:51:29 +0300,
Dan Partelly <dan_partelly@rdsor.ro> a écrit :

> I pointed this out 4-5 weeks ago when trying GuixSD, on this very
> list. Thanks for reaffirming  the idea In all honesty the current
> model is very badly broken, and you should not wait for 1.0. I had no
> other Linux distro break up faster than GuixSD. A stable branch is
> not enough by itself,  (but is the mort important part) you need to
> ensure that all substitutes are built correctly, and atomically
> update all substitutes following a successful build of all packages. 
> 
>  You should not inflict  current model on your users , not  even for
> an 0.1

Actually, this proposal has the side effect that anyone pulling to
stable will have all their substitutes available if the packages they
want were built at some point in time. This means that upgrading a
system or profile will always succeed and use substitutes, but it
doesn't give any guarantee on adding a package to the system or a user
profile.

> 
> 
> 
> > On Jul 29, 2018, at 12:40, Julien Lepiller <julien@lepiller.eu>
> > wrote:
> > 
> > Hi guix!
> > 
> > I recently had an idea about how we should organize ourworkflow for
> > post 1.0. The goal is to ensure that users can always update their
> > system.
> > 
> > Currently, we push updatesto master and they may not build on other
> > architectures or break dependant packages. This is bad because a
> > security update might get blocked because an unrelated package now
> > fails to build.
> > 
> > I'd like to propose the following policy:
> > 
> > We wouldcreate a new branch, stable, that would be used by guix
> > pull. We would continue to push to master or other branches.
> > 
> > Once hydra finds it can build at least as many packages in master
> > than stable, it would make master the new stable, hopefully once a
> > day or so.
> > 
> > Security updates would be provided to users by a seéarate channel,
> > to ensure important updates are delivered immediately to users.
> > 
> > Another possibility is to use a patch management system like gerrit
> > with a similar policy.
> > 
> > WDYT?
> >   

Re: Ensuring we don't break user systems

[Dan Partelly]

It also has the effect that guix is pulled from a reasonably tested branch and it is proven that it compiles. Given how central the package manager is to the GuixSD, this is something which IMO should have been done from long ago. IT saves users time, 
and show the developers care , if nothing else. But yeah, this proposal is IMO sound both technically and socially.

> system or profile will always succeed and use substitutes, but it
> doesn't give any guarantee on adding a package to the system or a user
> profile.
> 
>> 
>> 
>> 
>>> On Jul 29, 2018, at 12:40, Julien Lepiller <julien@lepiller.eu>
>>> wrote:
>>> 
>>> Hi guix!
>>> 
>>> I recently had an idea about how we should organize ourworkflow for
>>> post 1.0. The goal is to ensure that users can always update their
>>> system.
>>> 
>>> Currently, we push updatesto master and they may not build on other
>>> architectures or break dependant packages. This is bad because a
>>> security update might get blocked because an unrelated package now
>>> fails to build.
>>> 
>>> I'd like to propose the following policy:
>>> 
>>> We wouldcreate a new branch, stable, that would be used by guix
>>> pull. We would continue to push to master or other branches.
>>> 
>>> Once hydra finds it can build at least as many packages in master
>>> than stable, it would make master the new stable, hopefully once a
>>> day or so.
>>> 
>>> Security updates would be provided to users by a seéarate channel,
>>> to ensure important updates are delivered immediately to users.
>>> 
>>> Another possibility is to use a patch management system like gerrit
>>> with a similar policy.
>>> 
>>> WDYT?
>>> 
> 
> 

Re: Ensuring we don't break user systems

[Ludovic Courtès]

Hello!

Julien Lepiller <julien@lepiller.eu> skribis:

> I'd like to propose the following policy:
>
> We wouldcreate a new branch, stable, that would be used by guix pull. We would continue to push to master or other branches.
>
> Once hydra finds it can build at least as many packages in master than stable, it would make master the new stable, hopefully once a day or so.

I’m all for it.  We “just” need support for this in Cuirass and/or some
other tool…

Ludo’.

Re: Ensuring we don't break user systems

[Dan Partelly]

However, you do not need any tool support to switch a “stable” branch as a first step , ensuring you inimize the OS user exposure to both serious Guix bugs and potential Guile bugs. 

> On Jul 30, 2018, at 02:41, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> Hello!
> 
> Julien Lepiller <julien@lepiller.eu> skribis:
> 
>> I'd like to propose the following policy:
>> 
>> We wouldcreate a new branch, stable, that would be used by guix pull. We would continue to push to master or other branches.
>> 
>> Once hydra finds it can build at least as many packages in master than stable, it would make master the new stable, hopefully once a day or so.
> 
> I’m all for it.  We “just” need support for this in Cuirass and/or some
> other tool…
> 
> Ludo’.
> 

Re: Ensuring we don't break user systems

[Hartmut Goebel]

Julien Lepiller <julien@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

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Ensuring we don't break user systems

[Pjotr Prins]

On Mon, Jul 30, 2018 at 12:58:08PM +0200, Hartmut Goebel wrote:
> Julien Lepiller <julien@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.

Pj.

Re: Ensuring we don't break user systems

[Clément Lassieur]

Hi Pjotr,

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Mon, Jul 30, 2018 at 12:58:08PM +0200, Hartmut Goebel wrote:
>> Julien Lepiller <julien@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.

Re: Ensuring we don't break user systems

[Julien Lepiller]

Le Tue, 31 Jul 2018 15:15:24 +0200,
Clément Lassieur <clement@lassieur.org> a écrit :

> Hi Pjotr,
> 
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > On Mon, Jul 30, 2018 at 12:58:08PM +0200, Hartmut Goebel wrote:  
> >> Julien Lepiller <julien@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.