Re: Release v1.4?

On Wed, Jun 22, 2022 at 03:31:34PM +0200, Ludovic Courtès wrote: > Hi, > > Brian Cully skribis: > > > Ludovic Courtès writes: > > > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds like > >> a > >> recipe for a poor user experience, no? > > > > The mainline Emacs is not

Re: Release v1.4?

Hi, Brian Cully skribis: > Ludovic Courtès writes: > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds like >> a >> recipe for a poor user experience, no? > > The mainline Emacs is not Wayland-native, but it (along with just > about everything else) will run fine under

Re: Release v1.4?

On Fri, Jun 17, 2022, at 11:37 AM, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > Ludovic Courtès writes: > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds >> like a >> recipe for a poor user experience, no? > > The mainline Emacs is not

Further thoughts on Xorg "vs" Wayland etc -- was: Re: Release v1.4?

Hi brian, et al, On +2022-06-17 11:37:18 -0400, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > > Ludovic Courtès writes: > > > So plain ‘emacs’ package doesn’t work on Wayland? That sounds like a > > recipe for a poor user experience, no? > > The mainline

Re: Release v1.4?

Ludovic Courtès writes: So plain ‘emacs’ package doesn’t work on Wayland? That sounds like a recipe for a poor user experience, no? The mainline Emacs is not Wayland-native, but it (along with just about everything else) will run fine under XWayland. It's how I've been running it for

Re: Release v1.4?

Hi, Josselin Poiret skribis: > I'm not sure, it does seem like a fraction of people use it on IRC but > then again it's more likely that Wayland users would talk about it, X > being the default. If there are no outstanding bugs with Wayland Gnome > though, I think it'd be a better choice: no

Re: Release v1.4?

Hello, Ludovic Courtès writes: >> * switching gdm-configuration-wayland? to #t, so that the OOB experience >> with Wayland sessions is better. > > Perhaps I’m biased because I use Xorg, but I wonder how good a default > that is? To put it differently, what fraction of the user base uses >

Re: Release v1.4?

Hello, Ludovic Courtès ezt írta (időpont: 2022. jún. 15., Sze 11:12): > Hello! > > Josselin Poiret skribis: > > > Should we also make use of the point release to remove some deprecated > > things/switch some defaults? I'm thinking of: > > * removing the swap-devices deprecation warning and

Re: Release v1.4?

Hello! Josselin Poiret skribis: > Should we also make use of the point release to remove some deprecated > things/switch some defaults? I'm thinking of: > * removing the swap-devices deprecation warning and compatibility code; > * removing the bootloader-configuration-target warning and

Re: Release v1.4?

Hello everyone, Ludovic Courtès writes: > Thanks for the heads-up! I think merging ‘staging’ should be > top-priority. People are welcome to upgrade/reconfigure from it with: I'm currently running on staging with no bugs to report (x86_64-linux)! Should we also make use of the point release

Re: Release v1.4?

Hello, vi...@riseup.net writes: > On 2022-06-06 01:57, zimoun wrote: >> Hi, >> >> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: >> >>> guix time-machine --branch=staging -- … >>> >>> Remaining things to check: >>> >>> - [ ] system tests >>> - [ ] status on non-x86_64

Re: Release v1.4?

On 2022-06-06 01:57, zimoun wrote: > Hi, > > On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: > >> guix time-machine --branch=staging -- … >> >> Remaining things to check: >> >> - [ ] system tests >> - [ ] status on non-x86_64 architectures > > I agree. To me, it is part of the same

Re: Release v1.4?

Hi, On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: > guix time-machine --branch=staging -- … > > Remaining things to check: > > - [ ] system tests > - [ ] status on non-x86_64 architectures I agree. To me, it is part of the same effort. From my point of view, we missed the window

Re: Release v1.4?

Hello! zimoun skribis: > Schedule a release is the occasion to tackle some not-so-fun tasks as > merging the ’staging’ branch [1], many upgrades as Haskell [2] or Julia, > etc. Thanks for the heads-up! I think merging ‘staging’ should be top-priority. People are welcome to

Release v1.4?

Hi, It is time for a release! We were almost there on January… time flies. ;-) Many things are pending and I feel we need a small impulsion for a general motivation. :-) Well, it seems conditioned by the status of the build farms. Is all fine in this area? Schedule a release is the occasion

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! For the record, I created a few days ago an issue to keep track of progress towards the release by blocking it with issues that we think must be fixed before we release: https://issues.guix.gnu.org/53214 Click on “Details” to see the blocking issues. Hopefully it’ll allow everyone of

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Chris, Chris Marusich writes: [...] > With Ludo's feedback, I was able to fix 52940 without rebuilding the > world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master. Can > you try merging master into your version-1.4.0 branch? Awesome! As you may have noticed, today

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-26, Maxim Cournoyer wrote: > Vagrant Cascadian writes: >> On 2021-12-19, Maxim Cournoyer wrote: >>> zimoun writes: Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do we go for v1.4 or v2.0? ... >> Would it be appropriate to fix the ~700 low-hanbging

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Maxim, Maxim Cournoyer writes: > Hello Chris, > > Chris Marusich writes: > >> Maxim Cournoyer writes: >> >>> About the current status, I'm nearing on pushing a version-1.4.0 branch >>> which is based on master with a few more (core-ish) updates. There's >>> still a few days ahead of that,

Re: Release v1.4 (or 2.0): process and schedule ?

Hello Chris, Chris Marusich writes: > Maxim Cournoyer writes: > >> About the current status, I'm nearing on pushing a version-1.4.0 branch >> which is based on master with a few more (core-ish) updates. There's >> still a few days ahead of that, so if you manage to get many of this >> kind of

Re: Release v1.4 (or 2.0): process and schedule ?

Maxim Cournoyer writes: > About the current status, I'm nearing on pushing a version-1.4.0 branch > which is based on master with a few more (core-ish) updates. There's > still a few days ahead of that, so if you manage to get many of this > kind of problems fixed & merged in master they can

Re: Release v1.4 (or 2.0): process and schedule ?

Hello, Ludovic Courtès writes: > Hello! > > Maxim Cournoyer skribis: > >> About the current status, I'm nearing on pushing a version-1.4.0 branch >> which is based on master with a few more (core-ish) updates. There's >> still a few days ahead of that, so if you manage to get many of this >>

Re: Release v1.4 (or 2.0): process and schedule ?

On 2022-01-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> On 2021-12-21, Vagrant Cascadian wrote: > > [...] > >>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >>> are identified by: >>> >>> guix lint --checkers=description,synopsis > > [...] > >> Could guix

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! Maxim Cournoyer skribis: > About the current status, I'm nearing on pushing a version-1.4.0 branch > which is based on master with a few more (core-ish) updates. There's > still a few days ahead of that, so if you manage to get many of this > kind of problems fixed & merged in master

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! Vagrant Cascadian skribis: > On 2021-12-21, Vagrant Cascadian wrote: [...] >> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >> are identified by: >> >> guix lint --checkers=description,synopsis [...] > Could guix style be adapted to apply some of these

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Vagrant, Vagrant Cascadian writes: > On 2021-12-19, Maxim Cournoyer wrote: >> zimoun writes: >>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >>> we go for v1.4 or v2.0? >> >> As I've mentioned previously, I'd go for a 1.4.0 release, since overall >> we've refined

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-21, Vagrant Cascadian wrote: > On 2021-12-19, Maxim Cournoyer wrote: >> zimoun writes: >>> In both case, what is the target for a release date? I propose January >>> 31rst. WDYT? >> >> I'd like to fix #52051 before issuing the first release candidate (RC). >> Assuming this can be

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-19, Maxim Cournoyer wrote: > zimoun writes: >> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >> we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall > we've refined and improved (greatly!) what we already had

Re: Release v1.4 (or 2.0): process and schedule ?

Hi, On Mon, 20 Dec 2021 at 22:24, Ludovic Courtès wrote: > Same here. But first it’d be nice to come up with a summary of what we > did in ‘core-updates’ because I think we’ve all forgotten most of it. > :-) A summary as a ChangeLog or a summary as a blog post? :-) Cheers, simon

Re: Release v1.4 (or 2.0): process and schedule ?

Hi, zimoun skribis: > On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer > wrote: >> zimoun writes: > >>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >>> we go for v1.4 or v2.0? >> >> As I've mentioned previously, I'd go for a 1.4.0 release, since overall >> we've

Re: Release v1.4 (or 2.0): process and schedule ?

Hi all, On +2021-12-19 21:12:36 -0500, Maxim Cournoyer wrote: > Hi Simon, > > zimoun writes: > > > Hi, > > > > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do > > we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall >

Re: Release v1.4 (or 2.0): process and schedule ?

On Mon, 20 Dec 2021 at 10:04, zimoun wrote: >> I'd like to fix #52051 before issuing the first release candidate (RC). >> Assuming this can be made before the end of January with the first RC >> coming out around New Year, and that the kind of collaboration I've seen >> in the last weeks

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Maxim, On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer wrote: > zimoun writes: >> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >> we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall > we've refined and improved

Re: Release v1.4 (or 2.0): process and schedule ?

On Sun, 19 Dec 2021 21:12:36 -0500 Maxim Cournoyer wrote: > Hi Simon, > > zimoun writes: > > > Hi, > > > > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. > > Do we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since > overall we've

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Simon, zimoun writes: > Hi, > > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do > we go for v1.4 or v2.0? As I've mentioned previously, I'd go for a 1.4.0 release, since overall we've refined and improved (greatly!) what we already had rather than introduced

Release v1.4 (or 2.0): process and schedule ?

Hi, Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do we go for v1.4 or v2.0? In both case, what is the target for a release date? I propose January 31rst. WDYT? 1: 2: