Le Tue, 31 Jul 2018 15:15:24 +0200,
Clément Lassieur a écrit :
> Hi Pjotr,
>
> Pjotr Prins writes:
>
> > On Mon, Jul 30, 2018 at 12:58:08PM +0200, Hartmut Goebel wrote:
> >> Julien Lepiller skribis:
> >> >> We wouldcreate a new branch, stable, that would be used by guix
> >> >> pull. We
Hi Pjotr,
Pjotr Prins writes:
> On Mon, Jul 30, 2018 at 12:58:08PM +0200, Hartmut Goebel wrote:
>> Julien Lepiller 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
On Mon, Jul 30, 2018 at 12:58:08PM +0200, Hartmut Goebel wrote:
> Julien Lepiller 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
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
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
Amirouche Boubekki transcribed 7.8K bytes:
> Le lun. 30 juil. 2018 à 23:17, Nils Gillmann 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
> >
Le lun. 30 juil. 2018 à 23:17, Nils Gillmann 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
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
Julien Lepiller 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.goe...@crazy-compilers.com |
| www.crazy-compilers.com |
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 wrote:
>
> Hello!
>
> Julien Lepiller skribis:
>
>> I'd like
Hello!
Julien Lepiller 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 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
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
Le Sun, 29 Jul 2018 19:51:29 +0300,
Dan Partelly 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
Dan Partelly 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
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
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,
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
signature.asc
Description:
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
19 matches
Mail list logo
