From: 0x5c <0x5c@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: .github/ISSUE_TEMPLATE: add bug report and package request issue forms
Date: Thu, 31 Mar 2022 03:29:54 +0200 [thread overview]
Message-ID: <20220331012954.TR9dzIAYUGHe0aCrEJUT3aOPzQEai5nlDF3Ey_1tub0@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-36411@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
New comment by 0x5c on void-packages repository
https://github.com/void-linux/void-packages/pull/36411#issuecomment-1083942933
Comment:
> * checkboxes re-introduce _tasks_ we have just got rid of
This is behaviour we did not expect, as it was different at some point in the past (simply using text instead of markdown checkboxes). We'll do some tests to see what can be done about that, y/n dropdowns are likely to do the trick
> * mandatory checkboxes are dumb on their own anyway
The goal is to limit what can be requested (only released software, which is void's policy on new packages) and limit duplicates reports (which are extra work and are likely to create obsolete reports)
> * in bug report: there is no need for _update of package_ section
You're likely to have someone who considers old, but otherwise functioning, versions of packages to be "bugs". That text can be removed but it's not gonna be a meaningful change since it's not rendered in the final issue anyways.
> * in bug report: system info should not be mandatory, sometimes it's obvious it doesn't matter
I wonder if it's more obvious to maintainers than to bug reporters, and I suspect that without it being provided, the case it's needed would only be discovered beyond the point the reporter has gone AWOL
> * in bug report: _Bug description_ section should keep it's current name, _Actual behavior_
> * in package request: there should be a field to provide homepage
Consider those fixed
next prev parent reply other threads:[~2022-03-31 1:29 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 5:34 [PR PATCH] " classabbyamp
2022-03-30 8:37 ` [PR REVIEW] " paper42
2022-03-30 8:37 ` paper42
2022-03-30 8:40 ` paper42
2022-03-30 16:56 ` classabbyamp
2022-03-30 18:14 ` Chocimier
2022-03-30 23:39 ` [PR REVIEW] " 0x5c
2022-03-31 0:38 ` 0x5c
2022-03-31 1:29 ` 0x5c [this message]
2022-04-01 17:49 ` [PR PATCH] [Updated] " classabbyamp
2022-04-01 17:52 ` classabbyamp
2022-04-01 17:53 ` classabbyamp
2022-04-01 17:54 ` classabbyamp
2022-04-01 17:55 ` classabbyamp
2022-04-01 17:58 ` classabbyamp
2022-04-02 21:39 ` [PR PATCH] [Updated] " classabbyamp
2022-04-14 18:44 ` classabbyamp
2022-04-14 18:44 ` classabbyamp
2022-04-14 20:25 ` classabbyamp
2022-04-14 20:38 ` [PR REVIEW] " paper42
2022-04-14 20:38 ` paper42
2022-04-14 20:40 ` classabbyamp
2022-04-14 20:43 ` [PR PATCH] [Updated] " classabbyamp
2022-04-14 20:46 ` [PR REVIEW] " classabbyamp
2022-04-14 20:50 ` 0x5c
2022-04-14 20:57 ` Chocimier
2022-04-14 20:58 ` [PR REVIEW] " 0x5c
2022-04-14 21:13 ` 0x5c
2022-04-14 21:22 ` [PR REVIEW] " paper42
2022-04-14 21:23 ` paper42
2022-04-14 21:23 ` classabbyamp
2022-04-14 21:23 ` classabbyamp
2022-04-14 21:25 ` paper42
2022-04-14 21:29 ` classabbyamp
2022-04-14 21:48 ` [PR PATCH] [Updated] " classabbyamp
2022-04-19 15:33 ` classabbyamp
2022-04-19 17:48 ` Chocimier
2022-04-19 17:59 ` [PR PATCH] [Updated] " classabbyamp
2022-04-19 18:00 ` classabbyamp
2022-04-19 18:00 ` classabbyamp
2022-05-01 6:36 ` [PR REVIEW] " 0x5c
2022-06-10 20:48 ` [PR PATCH] [Updated] " classabbyamp
2022-06-10 20:51 ` classabbyamp
2022-06-10 20:52 ` [PR REVIEW] " classabbyamp
2022-06-10 20:56 ` [PR PATCH] [Updated] " classabbyamp
2022-06-10 20:59 ` classabbyamp
2022-06-14 18:33 ` Chocimier
2022-06-14 19:26 ` [PR PATCH] [Updated] " classabbyamp
2022-06-14 19:27 ` classabbyamp
2022-06-14 19:27 ` classabbyamp
2022-06-14 19:33 ` Chocimier
2022-06-14 19:39 ` [PR PATCH] [Updated] " classabbyamp
2022-06-17 3:44 ` [PR PATCH] [Merged]: " classabbyamp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220331012954.TR9dzIAYUGHe0aCrEJUT3aOPzQEai5nlDF3Ey_1tub0@z \
--to=0x5c@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).