Deliver important Guix changes to users, please

Deliver important Guix changes to users, please

[znavko]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

I was reading this https://git.savannah.gnu.org/cgit/guix.git/log/?qt=grep&q=slim
and found a record '2019-03-28 services: desktop: Switch to GDM'.
This change had made users' configurations unworkable. Update to this commit could bring bothers.
I think it will be the best to have some layer of informative support for updates. Like this:

$ guix system --updates-available
Commit: 1 [two days ago]
Changes: some services are available now

Commit: 2
Changes: [red]Switch to GDM in %desktop-services. If your config is using %desktop-services, you need to check manual pages.[/red]

Commit: 3 (latest)
Changes: gc clear-generations added
$ guix package --updates-available=1week
90 new packages added.
15 packages updated.
New packages:
emacs-evil-lio, llgpl-license, ...
Changed package:
emacs 26.1 => 26.2
...
That will give some knowledge that your cool config might be wrong after update to the latest commit, where dm was switched to gdm.

I think news should be divided to
- 'packages news' defining the period,
- and 'system news', the default period is from your last `guix system reconfigure config.scm` or may be your last generation's date till now,

And sure news should be available from guix command.

There are tools for update guix from substitute servers: local or Internet. There is much info in cgit logs on gnu server... Want to read more with guix.

Would this kind of messages help people to bypass troubles in convenient way?

[-- Attachment #2: Type: text/html, Size: 2059 bytes --]

Re: Deliver important Guix changes to users, please

[Ludovic Courtès]

Hello,

znavko@disroot.org skribis:

> I think it will be the best to have some layer of informative support for updates. Like this:
>
> $ guix system --updates-available
> Commit: 1 [two days ago]
> Changes: some services are available now
>
> Commit: 2
> Changes: [red]Switch to GDM in %desktop-services. If your config is using %desktop-services, you need to check manual pages.[/red]
>
> Commit: 3 (latest)
> Changes: gc clear-generations added
> $ guix package --updates-available=1week
> 90 new packages added.
> 15 packages updated.
> New packages:
> emacs-evil-lio, llgpl-license, ...
> Changed package:
> emacs 26.1 => 26.2
> ...
> That will give some knowledge that your cool config might be wrong after update to the latest commit, where dm was switched to gdm.
>
> I think news should be divided to
> - 'packages news' defining the period,
> - and 'system news', the default period is from your last `guix system reconfigure config.scm` or may be your last generation's date till now,
>
> And sure news should be available from guix command.
>
> There are tools for update guix from substitute servers: local or Internet. There is much info in cgit logs on gnu server... Want to read more with guix.
>
> Would this kind of messages help people to bypass troubles in convenient way?

‘guix pull’ already provides high-level “package news”, but I agree it’d
be nice to have a way to convey “system news” and perhaps free-form
messages like Debian’s change logs.

I suppose we could use some specially-formatted Git commits to pass
messages to users.  I’m afraid it would be hard to get those messages
translated.

Thoughts?

Note that the GDM change could also have been addressed by fixing
‘modify-services’ to report about unmatched service types, for example.

Thanks,
Ludo’.

Re: Deliver important Guix changes to users, please

[Amin Bandali]

Hi Ludo’, all,

On 2019-04-15  2:56 PM, Ludovic Courtès wrote:

[...]

>
> ‘guix pull’ already provides high-level “package news”, but I agree it’d
> be nice to have a way to convey “system news” and perhaps free-form
> messages like Debian’s change logs.
>
> I suppose we could use some specially-formatted Git commits to pass
> messages to users.  I’m afraid it would be hard to get those messages
> translated.
>
> Thoughts?
>

That’s an interesting idea.  Another alternative, perhaps, could be
having a “news” or “breaking changes” section/topic on the Guix blog,
ideally with a dedicated atom feed, where one could follow changes with
drastic change in system and/or package behaviour, or ones potentially
requiring a manual intervention of sorts.  Both Parabola and Hyperbola
have that section on their website, with latest news shown on the front
page.

Thoughts?

Best,
amin

Re: Deliver important Guix changes to users, please

[Brett Gilio]

Amin Bandali writes:

> Hi Ludo’, all,
>
> On 2019-04-15  2:56 PM, Ludovic Courtès wrote:
>
> [...]
>
>>
>> ‘guix pull’ already provides high-level “package news”, but I agree it’d
>> be nice to have a way to convey “system news” and perhaps free-form
>> messages like Debian’s change logs.
>>
>> I suppose we could use some specially-formatted Git commits to pass
>> messages to users.  I’m afraid it would be hard to get those messages
>> translated.
>>
>> Thoughts?
>>
>
> That’s an interesting idea.  Another alternative, perhaps, could be
> having a “news” or “breaking changes” section/topic on the Guix blog,
> ideally with a dedicated atom feed, where one could follow changes with
> drastic change in system and/or package behaviour, or ones potentially
> requiring a manual intervention of sorts.  Both Parabola and Hyperbola
> have that section on their website, with latest news shown on the front
> page.
>
> Thoughts?
>
> Best,
> amin

I second this idea.

Re: Deliver important Guix changes to users, please

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

Ludo', Guix,

As your friendly neighbourhood update bot, I read a lot of change 
logs.  The worst are the one-log text file with ’lol use git now, 
change logs are obsolete!1’.  Utterly clueless, distressingly 
common.

The best ones are usually called NEWS for some reason (go GNU!) 
and are manually maintained, in sync with the code changes but not 
forced on top of them; using git but not abusing it.

Ludovic Courtès wrote:
> I suppose we could use some specially-formatted Git commits to 
> pass
> messages to users.  I’m afraid it would be hard to get those 
> messages
> translated.

I beg you not to do this, even as fodder for a friendly front end. 
Just use a structured text file.  Add dates.  Affected packages. 
Metadata.  Hell, use sexps if you like.  Fix typos/add caveats to 
old news items when needed, not through errata commits.  Don't 
confuse git log with a log like some people confuse git blame with 
comments.

That is all,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Deliver important Guix changes to users, please

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

Tobias Geerinckx-Rice wrote:
> As your friendly neighbourhood update bot, I read a lot of 
> change
> logs.  The worst are the one-log text file with ’lol use git 
> now,
> change logs are obsolete!1’.  Utterly clueless, distressingly 
> common.

(I know that's not exactly what you're suggesting, but we'd be 
forcing ourselves into the same straightjacket for no clear 
benefit.)

(But hey, blockchain.)

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Deliver important Guix changes to users, please

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Ludovic Courtès wrote:
>> I suppose we could use some specially-formatted Git commits to pass
>> messages to users.  I’m afraid it would be hard to get those
>> messages
>> translated.
>
> I beg you not to do this, even as fodder for a friendly front
> end. Just use a structured text file.  Add dates.  Affected
> packages. Metadata.  Hell, use sexps if you like.  Fix typos/add
> caveats to old news items when needed, not through errata commits.
> Don't confuse git log with a log like some people confuse git blame
> with comments.

The interesting part here is that commits are anchored in the version
control history.  Thus, you could easily tell whether a news item is
relevant or not.

If you store news separately, well I guess you could just write the
commit to which the news item applies.

Hmm, maybe you’re right!

So we could have, say:

  .news/[0-9]+.news (every other file would be ignored)

and then some sexp format, say:

  (news
    (entry
      (title "GDM is now the default")
      (commit "cabba9e")
      (body "Hey, GDM’s in the house!"))
    (entry
      (title "News are here")
      …))

and we could maybe even have a PO file for this.

How does that sound?

(Probably post 1.0, but worth discussing.)

Ludo’.

Re: Deliver important Guix changes to users, please

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Ludo',

Ludovic Courtès wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
>
>> Ludovic Courtès wrote:
>>> I suppose we could use some specially-formatted Git commits to 
>>> pass
>>> messages to users.  I’m afraid it would be hard to get those
>>> messages
>>> translated.
>>
>> I beg you not to do this, even as fodder for a friendly front
>> end. Just use a structured text file.  Add dates.  Affected
>> packages. Metadata.  Hell, use sexps if you like.  Fix 
>> typos/add
>> caveats to old news items when needed, not through errata 
>> commits.
>> Don't confuse git log with a log like some people confuse git 
>> blame
>> with comments.
>
> The interesting part here is that commits are anchored in the 
> version
> control history.  Thus, you could easily tell whether a news 
> item is
> relevant or not.

Oh, sure.

To clarify: I'm pro storing the news items in the repository.  In 
fact I think it's a bad idea to keep it anywhere else (such as the 
Web site, but by all means generate a pretty news feed from 
guix.git on there).

I just think it should be a regular file.  Don't shove News 
metadata into the commit message.  When it makes sense, update the 
News file(s) in the same commit as the code — as is done for other 
documentation, which is what this is.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Deliver important Guix changes to users, please

[znavko]

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

Hello, Ludovic!
If commit has important meaning for all Guix users, it must give a short news entry for the users that are now developers and do not really read git logs.

How to perform this?
There are git commit messages that may have some specific rule for containing news.
For example, your commit https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/services?id=305a732a0a19c5810aab401aa7d70eba02ac386b
may have 'message' field like this:
news: services: xorg: Add 'set-xorg-configuration'.

Placing 'news:' makes this message important for the guix informer. It will react to the 'news:' messages.

If it is not possible to use the 'message field', then need to add news.log file into Guix git tree, and there, developers may add important news with their commits.

Adding 'news' prefix means this message will regard as message for delivery to Guix users when they run `guix pull` or when they order news with command like `guix news`.
The set of these news assembled from commits (or from the news.log that also may contain date field) for any defined period will be displaying to Guix users.

`guix news` may have default period from the last `guix pull` running till now, also may have the 'period' option.

I really think your distribution is effective and powerful.
If I'd be a bank's sysadmin, I use Guix, having my own troubles in my local network, having my local substitute server and special Guix configurations on each work place This news function can help me to solve: to update or not to update.
Seeing if there are sensitive changes that may break bank's work places, I will check the manual first before update.
April 15, 2019 12:56 PM, "Ludovic Courtès" <ludo@gnu.org (mailto:ludo@gnu.org)> wrote:
 Hello,

znavko@disroot.org (mailto:znavko@disroot.org) skribis:
 I think it will be the best to have some layer of informative support for updates. Like this:

$ guix system --updates-available
Commit: 1 [two days ago]
Changes: some services are available now

Commit: 2
Changes: [red]Switch to GDM in %desktop-services. If your config is using %desktop-services, you
need to check manual pages.[/red]

Commit: 3 (latest)
Changes: gc clear-generations added
$ guix package --updates-available=1week
90 new packages added.
15 packages updated.
New packages:
emacs-evil-lio, llgpl-license, ...
Changed package:
emacs 26.1 => 26.2
...
That will give some knowledge that your cool config might be wrong after update to the latest
commit, where dm was switched to gdm.

I think news should be divided to
- 'packages news' defining the period,
- and 'system news', the default period is from your last `guix system reconfigure config.scm` or
may be your last generation's date till now,

And sure news should be available from guix command.

There are tools for update guix from substitute servers: local or Internet. There is much info in
cgit logs on gnu server... Want to read more with guix.

Would this kind of messages help people to bypass troubles in convenient way? 

‘guix pull’ already provides high-level “package news”, but I agree it’d
be nice to have a way to convey “system news” and perhaps free-form
messages like Debian’s change logs.

I suppose we could use some specially-formatted Git commits to pass
messages to users. I’m afraid it would be hard to get those messages
translated.

Thoughts?

Note that the GDM change could also have been addressed by fixing
‘modify-services’ to report about unmatched service types, for example.

Thanks,
Ludo’.

[-- Attachment #2: Type: text/html, Size: 4191 bytes --]