Re: Deliver important Guix changes to users, please
Ludo', Ludovic Courtès wrote: Tobias Geerinckx-Rice 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 signature.asc Description: PGP signature
Re: Deliver important Guix changes to users, please
Hello, Tobias Geerinckx-Rice 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
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 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 signature.asc Description: PGP signature
Re: Deliver important Guix changes to users, please
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 signature.asc Description: PGP signature
Re: Deliver important Guix changes to users, please
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" mailto:l...@gnu.org)> wrote: Hello, zna...@disroot.org (mailto:zna...@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
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
Hello, zna...@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’.
Deliver important Guix changes to users, please
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?
