[arch-dev-public] New ideas for notifying users about (minor) changes

[Eli Schwartz]

On 7/29/19 6:47 PM, Christian Rebischke via arch-dev-public wrote:
> Hello everybody,
> I got assigned to this issue here:
> 
> https://bugs.archlinux.org/task/62823
> 
> The users would like to have a notice in pre/post install/upgrade
> notifications via pacman .install files.
> 
> I am not a fan of spamming such news via pacman and I think the
> installation/upgrade process should be clean of such messages, but I
> don't have access to the news tool on our website as well.

It's not unreasonable to add such post_upgrade messages in cases where
you want to ensure the user sees the message.

> So what can we do here? I am a big fan of Gentoos Newsletter feature[1].
> It would be super awesome if we would have a tool such like `archnews
> <packagename>` to retrieve NEWS about a certain package from an
> endpoint. This endpoint should be controllable by every maintainer (devs
> and TUs included). I discussed this with coderobe a bit and we came to
> different solutions:
> 
> 
> Solution 1: a NEWS file inside of the package repository:
> --------------------------------------------------------
> 
> A maintainer could upload a `NEWS` file into the package repository and
> then a client could grab this information directly via downloading the
> file from:
> 
> https://git.archlinux.org/svntogit/community.git/plain/trunk/NEWS?h=packages/0ad
> 
> Pro:
> + every maintainer could control this NEWS file easily via our current
> tools.
> + It's easy to download the NEWS files (we can expect new tools from the
> community)
> 
> Con:
> - We bloat our repository

We already have this feature.

Add the following to the PKGBUILD, and rebuild it:

changelog=NEWS

Now, the user may at any time run the following command for an installed
package:

$ pacman -Qc pkgname
Changelog for pkgname:
[contents of NEWS file]

Changelogs are pacman's #1 unused feature. Do note, however, that these
messages are opt-in and thus users won't see them unless they know they
need to. As such, it makes sense for a "changelog", but its utility as a
news bulletin may be in doubt.

> Solution 2: commit messages as NEWS
> ------------------------------------
> 
> The maintainer could/should put such news into the latest commit
> message.
> 
> Pro:
> + no extra file
> + using existing infrastructure
> + one workflow
> 
> Con:
> - I need an actual change in the repository to create a new NEWS object
>   (If we have a look on my example with strongswan, I would need to add
>   something in the PKGBUILD to make a new commit to make a new NEWS
>   object)
> - It's more difficult to get with tools. The user needs to checkout the
>   repository (in solution 1 it can be just a curl call)

People should already use decent commit messages. But we should *not*
abuse them to contain information that is not about what the commit did,
but instead about how users should respond to the new package release.

That duplicates the functionality of a changelog without offering a
compelling use case that it would be better at. It additionally makes
commit messages *worse* at effectively doing the job of a commit message.

> Solution 3: A webapp on news.archlinux.org with a fancy UI
> -----------------------------------------------------------
> 
> This solution would be the most work. We could have a new webapp (such
> like our security tracker) just for NEWS objects. Every maintainer
> should have access to their assigned packages.
> 
> Pro:
> + Fancy
> + Easy to use
> + API endpoints
> 
> Con:
> - A lot of work
> -------------------------------------------------------------

That duplicates the functionality of a changelog without offering a
compelling use case that it would be better at. The only thing that
would be possible with this, that a changelog cannot do, is tell you
about the news for a package you don't have installed, but I assume you
don't actually care about that.

> I would go for solution 1. What would be interesting to know for me:
> 
> 1. Do you think that we actually *need* such a tool?
> 2. Would you use such a tool/workflow?
> 3. Do you have other/better ideas?

I do not thing we need such a tool, and if we had one, I would refuse to
use it -- instead opting to use the changelog feature.

I would still use post_upgrade messages that use vercmp to make sure
they run exactly once, to alert users to important issues surrounding a
new release that I do not want them to accidentally miss.

See community/sigil for an example of using post_upgrade for warnings
that I want all users to see.

See community/fanficfare for an example of using changelogs to make the
list of changes in the package, more accessible.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190729/61cddd91/attachment.sig>