Hi all,
On Fri, Dec 13, 2024 at 03:08 PM, Felix Lechner via \"Development of GNU Guix
and the GNU System distribution.\" wrote:
> On Fri, Dec 13 2024, Ricardo Wurmus wrote:
>
>> Our releases should mean something.
>
> What do they mean, please?
>
This is actually related to the topic I wanted t
Hi Ricardo,
On Fri, Dec 13 2024, Ricardo Wurmus wrote:
> Our releases should mean something.
What do they mean, please?
Kind regards
Felix
P.S. No flames, please. It's an innocent question.
Ricardo Wurmus writes:
> Suhail Singh writes:
>
>> Assuming my understanding above is correct, wouldn't you agree that
>> (even) for those individuals what's most important is that there is a
>> _stable_ and _not-very-outdated_ release available? My (and I believe
>> Greg's) contention is that
Tomas Volf <~@wolfsden.cz> writes:
> I would like to point out that there is more work involved than just
> splitting it into separate channels and adding those into
> %default-channels.
Could you please elaborate? Or were these the two points you noted
below?
> While multiple channels do work
Suhail Singh writes:
> Assuming my understanding above is correct, wouldn't you agree that
> (even) for those individuals what's most important is that there is a
> _stable_ and _not-very-outdated_ release available? My (and I believe
> Greg's) contention is that following a time-based release p
Hi Guix,
I've reconfigured my system with Sway and I noticed that GTK4
applications now ignore my input method. GTK3 applications and Emacs
still work fine.
GTK4 applications used to work with IBus under Gnome, so I'm guessing
that some more configuration is required to make this work... Does
a
>ven. 13 déc. 2024 at 12:21, Suhail Singh wrote:
> Is my understanding of your scenario as summarized below correct, could
> you please confirm?
>
> There are some individuals who would be able to follow the instructions
> to install Guix. However, these individuals wouldn't understand the
> in
Suhail Singh writes:
> Simon Josefsson via "Development of GNU Guix and the GNU System
> distribution." writes:
>
>> can we strip away almost all of the packages and still have a minimal
>> bootable system? If we minimize that set of really-core packages,
>> maybe there can be one team that wor
Simon Josefsson via "Development of GNU Guix and the GNU System
distribution." writes:
> can we strip away almost all of the packages and still have a minimal
> bootable system? If we minimize that set of really-core packages,
> maybe there can be one team that works on this minimal bootable OS
Cayetano Santos writes:
> Let me just play the dummies advocate for a moment ...
Thank you. I believe it is important to consider such scenarios (among
others).
> They will be doing `whatever install guix`, and then they’ll happily
> start using guix: with a bit of documentation, they’ll love
>ven. 13 déc. 2024 at 10:52, Suhail Singh wrote:
> Greg Hogan writes:
>
>> We only need a release team and a documented release process. Releases
>> should be scheduled rather than depending on other teams. What benefit
>> is there to the Guix user when glibc or the default gcc are updated?
>>
How much of the guix git repository content can you remove and still
have a working OS? In other words, can we strip away almost all of the
packages and still have a minimal bootable system? If we minimize that
set of really-core packages, maybe there can be one team that works on
this minimal bo
Suhail Singh writes:
> If the goal is to increase the frequency of releases while maintaining
> quality, the only consideration that the teams-branch ought to make is
> to ensure that the commit in question (corresponding to the release)
> b
Hey there,
https://qa.guix.gnu.org/ says it’s your turn to merge! :-)
Ludo’.
Greg Hogan writes:
> We only need a release team and a documented release process. Releases
> should be scheduled rather than depending on other teams. What benefit
> is there to the Guix user when glibc or the default gcc are updated?
> You're only a "guix pull" away from updated packages.
>
> A
On Fri, Dec 13, 2024 at 8:02 AM Suhail Singh wrote:
>
> Ricardo Wurmus writes:
>
> > Releases are made a short time after the core team branch is merged.
> > This would give us a new release whenever e.g. the default GCC and
> > glibc is bumped up. We could aim for a release two months after the
Ricardo Wurmus writes:
> Releases are made a short time after the core team branch is merged.
> This would give us a new release whenever e.g. the default GCC and
> glibc is bumped up. We could aim for a release two months after the
> merge to allow for minor fixes after the merge.
I think agre
Hello Guix,
grafts can be a little slow for a number of reasons:
- they are not substituted, because the assumption is that it is
preferrable to rewrite references locally instead of downloading a big
archive with the modified file. Local computations on x86_64 are
often acceptable, but on
Hi,
Thanks for moving this discussion forward. I do think we need much more
regular releases.
> - devel as the branch for developments, master for releases and
> security/bug fixes
Changing the branching model is very difficult to do. I think it is
better to ignore branches for now and focus
Hi Guix,
Let me spin off last year thread on releases (flavored by an external to
the project point of view), with the goal to relaunch the debate on
releases.
Disclaimer: the rolling release model is great and more than enough for
me, and teams constitute an mportant step forward.
Disclaimer 2
20 matches
Mail list logo
