Feature request: Per package note

[felixonmars]

I would like to write a per package note mostly for out-of-date packages to explain why they cannot be updated.

Some of us currently abuse the out-of-date system by un-flagging the package and flagging out-of-date again with some text. But it's not accessible to public, so users still ask again and again.

[BrainDamage]

Some excerpt from a related discussion on irc:

a> but that note will still be used when we have the automatic flagging [ndr: of out-of-date] implemented?
b> maybe, why not?
b> seems to be to be completely seperate from it
a> guess it makes sense to
c> it should be, it still avoids user pestering the maintainer why a package was not updated

proposal for the interface to view the entry:

Visually, another line after "Last Updated:", title "Pinned Due:" and follows a line of text which can contain a hyperlink. The hyperlink can be a link to a bug ticket or whatnot. In order to allow maximum flexibility, ideally the entry should be parsed by the restricted markdown parser as aurweb comments already do. Updating the package should ideally auto-remove the line.

how to feed the data:

d> What if we allowed to read NOTE from the vcs dir?
b> parsing a vcs is a nono
c> currently the out-of-date mechanism is web only

proposal for element entry:

Text entry box with the usual ok button to submit, and a delete button; when viewing the package page and logged in as a package maintainer. Entering a new text should overwrite the current content. Content parsed using restricted markdown as previously mentioned.

[jelly]

The location under "Last Updated", might make the whole page a bit bloated if it's a very long line explaining why it isn't updated. However I am not sure what the alternative would be, a possibility is to display it on the flag package page.

Another option is to display it as how logged in users see it which is as following:

Which seems to be ok to me.

I will never add support to archweb to fetch data from VCS as this is way to complicated and requires keeping a whole git clone from our packages/community.git

I like the idea of keeping it in archweb, and removing the note when the package was updated to a new version.

[jelly]

Hacking a bit on it tonight, I was reminded I added this:

[yan12125]

make the whole page a bit bloated if it's a very long line explaining why it isn't updated.

How about limitimg the length of notes? Detailed comments can be in a file in VCS and archweb provides a link (ex: https://github.com/archlinux/svntogit-community/blob/packages/$pkgbase/trunk/NOTES).

[ArchangeGabriel]

make the whole page a bit bloated if it's a very long line explaining why it isn't updated.

How about limitimg the length of notes? Detailed comments can be in a file in VCS and archweb provides a link (ex: https://github.com/archlinux/svntogit-community/blob/packages/$pkgbase/trunk/NOTES).

I don’t think it’s a good idea to clobber the VCS tree with notes…

[yan12125]

If lengthy package notes are necessary, it's up to package maintainers to put them on archweb (may make web pages a bit bloated) or a link on archweb to somewhere in VCS.

Actually I add some notes to PKGBUILDs recently (ex: https://github.com/archlinux/svntogit-community/commit/c662448501b8a25fa1070595562986f4171c5df8). Not clobbering IMO.

[jelly]

So my latest ideas are:

• Show note in flagging form as shown above
• Change flagged out-of-date on X to show some sort of reference / link to the packaging note

Adding a package not with:

Drop the note when the package is updated to a new version.

[yan12125]

Thanks for the follow-up!

Show note in flagging form as shown above

Sounds like lengthy notes are no longer an issue?

[jelly]

Thanks for the follow-up!

Show note in flagging form as shown above

Sounds like lengthy notes are no longer an issue?

Lengthy notes are fine. I prefer not showing large notes expanded in the package details page, but we can either have some sort of popover or open the note in a new page. I am not 100% sure yet how we show the note as it could be about a non-flagged package I guess maybe it should be a new link.

[yan12125]

Is a popover like loaded/expanded contents after clicking "View the file list for $pkgname"? That sounds good as well.

maybe it should be a new link.

Yeah a new link sounds better. Package notes should not be limited to reasons for blocked updates ;)

[jelly]

no

Is a popover like loaded/expanded contents after clicking "View the file list for $pkgname"? That sounds good as well.

maybe it should be a new link.

Yeah a new link sounds better. Package notes should not be limited to reasons for blocked updates ;)

How do we get rid of those notes then? I guess we can add a delete button for when you are logged in as Packager? Or should it go away after an package update?

[yan12125]

How do we get rid of those notes then?

How about a check box [ ] Remove notes when the package is updated (possibly checked by default)?

In some special cases, it may be desired to keep notes for update-blocking reasons even after the package is updated. For example, gnupg may have a note like This package is kept on 2.2.x branch instead of upgraded to 2.3 because of https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/178. Such a note can be kept when gnupg is updated from 2.2.x to 2.2.x+1

we can add a delete button for when you are logged in as Packager?

I'm not sure clearing existing notes to dismiss them is intuitive or not. Adding a delete button is an option.