Re: Ensuring we don't break user systems

[Julien Lepiller <julien@lepiller.eu>]

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.