bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22629: “Stable” branch


From: Alex Sassmannshausen
Subject: bug#22629: “Stable” branch
Date: Thu, 30 Aug 2018 16:10:20 +0200
User-agent: mu4e 1.0; emacs 26.1

Ludovic Courtès writes:

> Hi Konrad,
>
> Konrad Hinsen <address@hidden> skribis:
>
>> The minimal stable foundation would have to include the file system
>> layout of profiles, to make sure that users can mix packages from both
>> versions safely. It would also be highly desirable to share the store,
>> whose layout would then have to be part of the foundation as well.
>>
>> Moreover, I suspect it would be preferable or even necessary to have
>> only one daemon running - if that's true, then the daemon's
>> communication protocol would have be part of the foundation as well.
>>
>> Without a common foundation, a stable version would have to be a
>> completely autonomous fork, which should then probably adopt a different
>> name as well. I don't think this is desirable, in particular for GuixSD
>> which would lose most of its interest if it required multiple package
>> managers.
>
> These are all things that very rarely, if ever, changed over the last 5
> years.  I expect the change rate to remain the same.  :-)
>
> You seem to be arguing of a “stable” branch in the sense that the Guix
> tools (the CLI in particular) wouldn’t change much, is that correct?
>
> I’m asking because there are several ways to define “stable.”  Initially
> I thought what you had in mind was like the “stable” branch in Debian,
> meaning that packages only get security updates.  To me that’s a
> different thing.

I don't know if this is what Konrad desires, but from my perspective, a
desirable part of the definition of stable would be a that the build
farms have produced a set of binaries/substitutes for a given Guix
revision that is "good enough".

Where good enough might mean something like "no more build failures than
the previous iteration", or "no more build failures on common desktop
applications" or other some exciting metric (the exact definition is not
really important right now).

The main concern here would be that we try to avoid end users from
having unexpected build failures or even missing substitutes after doing
a guix pull.

Alex





reply via email to

[Prev in Thread] Current Thread [Next in Thread]