README: add info about the github page
PATCH 1/1 README: add info about the github page
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
--- README | 5 +++++ 1 file changed, 5 insertions(+)
README +5 -0
@@ -294,9 +294,14 @@ Those also provide examples of the expected formatting. Allow some time for your e-mail to propagate to the list before retrying, particularly if there are no e-mails in the list more recent than yours. +There is a libgpiod github page[7] available for reporting bugs and general +discussions and although PRs can be submitted and discussed, upstreambound +patches need to go through the mailing list nevertheless. + [1] https://github.com/kward/shunit2 [2] http://vger.kernel.org/vger-lists.html#linux-gpio [3] https://docs.kernel.org/process/email-clients.html [4] https://docs.kernel.org/process/coding-style.html [5] https://docs.kernel.org/process/submitting-patches.html [6] https://lore.kernel.org/linux-gpio/ +[7] https://github.com/brgl/libgpiod
Signature · 1 line
2.40.1
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
No problem with the patch, but the github page itself seems to have Issues and Discussions disabled. And the Wiki might be useful too?
Quoted 27 lines
Signed-off-by Bartosz Golaszewski <[email protected]>--- README | 5 +++++ 1 file changed, 5 insertions(+)README +5
-1@@ -294,9 +294,14 @@ Those also provide examples of the expected formatting. Allow some time for your e-mail to propagate to the list before retrying, particularly if there are no e-mails in the list more recent than yours. +There is a libgpiod github page[7] available for reporting bugs and general +discussions and although PRs can be submitted and discussed, upstreambound +patches need to go through the mailing list nevertheless. + [1] https://github.com/kward/shunit2 [2] http://vger.kernel.org/vger-lists.html#linux-gpio [3] https://docs.kernel.org/process/email-clients.html [4] https://docs.kernel.org/process/coding-style.html [5] https://docs.kernel.org/process/submitting-patches.html [6] https://lore.kernel.org/linux-gpio/ +[7] https://github.com/brgl/libgpiod --2.40.1
Quoted 11 lines · Kent Gibson
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
No problem with the patch, but the github page itself seems to have Issues and Discussions disabled. And the Wiki might be useful too?
The Releases section could use updating - it lists the latest as v0.3 from June 2017!
And unless you intend to handle everything that lands there yourself you might want to add some of us as collaborators, with appropriate permissions for what you would like us to help out with.
Cheers,
Kent.
Quoted 10 lines · Kent Gibson
Quoted 8 lines · Kent Gibson
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
Quoted 7 lines
Quoted 3 lines
No problem with the patch, but the github page itself seems to have Issues and Discussions disabled. And the Wiki might be useful too?
The Releases section could use updating - it lists the latest as v0.3 from June 2017!
I don't want to do releases on github. The right place to fetch the releases from is kernel.org[1] (I should add this link to README too) and I don't want to duplicate release tarballs. I'm pretty sure people would start fetching releases from github for distros etc.
Bart
Quoted 6 lines
And unless you intend to handle everything that lands there yourself you might want to add some of us as collaborators, with appropriate permissions for what you would like us to help out with.
Cheers,
Kent.
[1] https://mirrors.edge.kernel.org/pub/software/libs/libgpiod/
Quoted 15 lines · Bartosz Golaszewski
Quoted 14 lines · Kent Gibson
Quoted 11 lines · Kent Gibson
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
No problem with the patch, but the github page itself seems to have Issues and Discussions disabled. And the Wiki might be useful too?
Quoted 8 lines
Quoted 3 lines
The Releases section could use updating - it lists the latest as v0.3 from June 2017!
I don't want to do releases on github. The right place to fetch the releases from is kernel.org[1] (I should add this link to README too) and I don't want to duplicate release tarballs. I'm pretty sure people would start fetching releases from github for distros etc.
You might want to delete the old tags from the github remote in that case. I think it might be a bit confusing to see v0.3 as "most recent" release otherwise.
- Erik
Quoted 21 lines · Erik Schilling
Quoted 19 lines · Bartosz Golaszewski
Quoted 17 lines · Kent Gibson
Quoted 11 lines · Kent Gibson
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
No problem with the patch, but the github page itself seems to have Issues and Discussions disabled. And the Wiki might be useful too?
The Releases section could use updating - it lists the latest as v0.3 from June 2017!
Quoted 9 lines
Quoted 4 lines
I don't want to do releases on github. The right place to fetch the releases from is kernel.org[1] (I should add this link to README too) and I don't want to duplicate release tarballs. I'm pretty sure people would start fetching releases from github for distros etc.
You might want to delete the old tags from the github remote in that case. I think it might be a bit confusing to see v0.3 as "most recent" release otherwise.
Yeah, I did that and only left master, v2.1.x and v1.6.x branches alive.
Bart
Quoted 15 lines · Bartosz Golaszewski
Quoted 14 lines · Kent Gibson
Quoted 11 lines · Kent Gibson
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
No problem with the patch, but the github page itself seems to have Issues and Discussions disabled. And the Wiki might be useful too?
Quoted 9 lines
Quoted 3 lines
The Releases section could use updating - it lists the latest as v0.3 from June 2017!
I don't want to do releases on github. The right place to fetch the releases from is kernel.org[1] (I should add this link to README too) and I don't want to duplicate release tarballs. I'm pretty sure people would start fetching releases from github for distros etc.
Uugh, yeah github automatically provides tarballs for releases and there is no way to disable that. I was thinking you could just use it to advertise a particular tag as a release, but don't want the additional tarballs floating around. So, yeah, definitely need to add links to the official sources for tarballs, cos they can still download a zip of the tree, even if you haven't provided the tags.
And, if you have time, adding an issue describing the daemon and where you are at would be really helpful. Though that is currently living in the topic/dbus branch of libgpiod-private, right?
Cheers,
Kent.
Quoted 20 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
Signed-off-by Bartosz Golaszewski <[email protected]>--- README | 5 +++++ 1 file changed, 5 insertions(+)README +1
-0@@ -294,9 +294,14 @@ Those also provide examples of the expected formatting. Allow some time for your e-mail to propagate to the list before retrying, particularly if there are no e-mails in the list more recent than yours. +There is a libgpiod github page[7] available for reporting bugs and general
README Those also provide examples of the expected formatting. · line 307
Quoted 10 lines
README +4
-0+discussions and although PRs can be submitted and discussed, upstreambound +patches need to go through the mailing list nevertheless. + [1] https://github.com/kward/shunit2 [2] http://vger.kernel.org/vger-lists.html#linux-gpio [3] https://docs.kernel.org/process/email-clients.html [4] https://docs.kernel.org/process/coding-style.html [5] https://docs.kernel.org/process/submitting-patches.html [6] https://lore.kernel.org/linux-gpio/ +[7] https://github.com/brgl/libgpiod
The repo only seems to be configured for PRs. Issues and discussions are disabled for the public.
- Erik
Quoted 36 lines · Erik Schilling
Quoted 20 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
Signed-off-by Bartosz Golaszewski <[email protected]>--- README | 5 +++++ 1 file changed, 5 insertions(+)README +1
-0@@ -294,9 +294,14 @@ Those also provide examples of the expected formatting. Allow some time for your e-mail to propagate to the list before retrying, particularly if there are no e-mails in the list more recent than yours. +There is a libgpiod github page[7] available for reporting bugs and generalREADME Those also provide examples of the expected formatting. · line 307
Quoted 10 lines
README +4
-0+discussions and although PRs can be submitted and discussed, upstreambound +patches need to go through the mailing list nevertheless. + [1] https://github.com/kward/shunit2 [2] http://vger.kernel.org/vger-lists.html#linux-gpio [3] https://docs.kernel.org/process/email-clients.html [4] https://docs.kernel.org/process/coding-style.html [5] https://docs.kernel.org/process/submitting-patches.html [6] https://lore.kernel.org/linux-gpio/ +[7] https://github.com/brgl/libgpiodThe repo only seems to be configured for PRs. Issues and discussions are disabled for the public.
Quoted 2 lines
- Erik
Should be good now. Should I create a wiki too?
Bart
Erik Schilling
Reviewed-byQuoted 38 lines · Bartosz Golaszewski
Quoted 36 lines · Erik Schilling
Quoted 20 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
The github page over at https://github.com/brgl/libgpiod has been reopened for bug reports and discussions. Add a link and a mention to the README file.
Signed-off-by Bartosz Golaszewski <[email protected]>--- README | 5 +++++ 1 file changed, 5 insertions(+)README +1
-0@@ -294,9 +294,14 @@ Those also provide examples of the expected formatting. Allow some time for your e-mail to propagate to the list before retrying, particularly if there are no e-mails in the list more recent than yours. +There is a libgpiod github page[7] available for reporting bugs and generalREADME Those also provide examples of the expected formatting. · line 307
Quoted 10 lines
README +4
-0+discussions and although PRs can be submitted and discussed, upstreambound +patches need to go through the mailing list nevertheless. + [1] https://github.com/kward/shunit2 [2] http://vger.kernel.org/vger-lists.html#linux-gpio [3] https://docs.kernel.org/process/email-clients.html [4] https://docs.kernel.org/process/coding-style.html [5] https://docs.kernel.org/process/submitting-patches.html [6] https://lore.kernel.org/linux-gpio/ +[7] https://github.com/brgl/libgpiodThe repo only seems to be configured for PRs. Issues and discussions are disabled for the public.
Quoted 4 lines
Quoted 2 lines
- Erik
Should be good now.
Quoted 1 line
Should I create a wiki too?
Got no opinion on that.
- Erik
Quoted 9 lines · Erik Schilling
Quoted 8 lines · Bartosz Golaszewski
Quoted 5 lines · Erik Schilling
disabled for the public.
- Erik
Quoted 8 lines
Quoted 1 line
Should be good now.
Reviewed-by Erik Schilling <[email protected]>Quoted 1 line
Should I create a wiki too?
Got no opinion on that.
I think the wiki could be useful for linking to things that aren't in the README or that you can't readily link to with a plain text README, like links to the readthedocs documentation, kernel patch submission process, maybe some hints on building for different distros (e.g. to identify packages that need to be installed first)....
And speaking of the README, just noticed it mentions 4.8 as being the first release of the uAPI, but libgpiod uses v2 exclusively, and that wasn't introduced until 5.10. We might want to update that - still mention 4.8, since you also mention deprecating sysfs, but also mention v2 and 5.10.
Cheers,
Kent.