Hello devel,
I got nerdslipped and I ahve created some HTML only mockup of a thing that I find very useful. A Fedora Packager Dashboard.
You can find the early mockup at:
https://hroncok.cz/packager-dashboard-mockup/
The idea is to collect some data about your packages and present them in some nice form. Such data would be gathered by plugins. Examples on the mockup:
- active updates - active buildroot overrides - open PRs - orphaned or broken depnddencies - bugzillas - FTBFS (from koschei)
Ideas not included in the mockup:
- running Koji builds
Let me know what you think. I can work on this on the backend level (plugin architecture design, gathering data, cache...) but even copy pasting HTML from Bodhi to present the mockup was very painful for me, so if we want this, somebody with more fronted experience would need to help.
On Sat, Dec 14, 2019 at 4:03 PM Miro Hrončok mhroncok@redhat.com wrote:
Hello devel,
Hey Miro!
I got nerdslipped and I ahve created some HTML only mockup of a thing that I find very useful. A Fedora Packager Dashboard.
You can find the early mockup at:
https://hroncok.cz/packager-dashboard-mockup/
The idea is to collect some data about your packages and present them in some nice form. Such data would be gathered by plugins. Examples on the mockup:
- active updates
- active buildroot overrides
- open PRs
- orphaned or broken depnddencies
- bugzillas
- FTBFS (from koschei)
Ideas not included in the mockup:
- running Koji builds
Let me know what you think. I can work on this on the backend level (plugin architecture design, gathering data, cache...) but even copy pasting HTML from Bodhi to present the mockup was very painful for me, so if we want this, somebody with more fronted experience would need to help.
Yeah, I think something like that is useful to keep an overview of things that are "in flight".
The new bodhi homepage is a good step in this direction, it already lists "active" updates and "active" buildroot overrides, which is nice: https://bodhi.fedoraproject.org/
Collecting this information + open PRs + broken/orphaned dependencies + FTBFS issues sounds like a good idea. I have the impression that these things could use more visibility.
FWIW, I'm also *very bad* at user-facing stuff (even HTML sometimes baffles me), but I could definitely help write some code :) I already have some of that stuff available in miscellaneous scripts (Stewardship SIG maintenance scripts, fedora-health-check, fedora-update-notifier) and am familiar with bodhi/koji/pagure API from my side projects (bodhi-rs, and the WIP koji-rs and pagure-rs). Though I think you'll probably want to have this dashboard powered by python, not by rust :)
Fabio
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 15. 12. 19 10:09, Fabio Valentini wrote:> The new bodhi homepage is a good step in this direction, it already
lists "active" updates and "active" buildroot overrides, which is nice: https://bodhi.fedoraproject.org/
That's where I started.
Collecting this information + open PRs + broken/orphaned dependencies
- FTBFS issues sounds like a good idea.
I have the impression that these things could use more visibility.
FWIW, I'm also *very bad* at user-facing stuff (even HTML sometimes baffles me), but I could definitely help write some code :) I already have some of that stuff available in miscellaneous scripts (Stewardship SIG maintenance scripts, fedora-health-check, fedora-update-notifier)
I have plenty of stuff scattered in various scripts as well. For most of the data, I know how to collect it somehow - the important parts will be to do it:
- in fast/efficient way - via sustainable and maintainable code
and am familiar with bodhi/koji/pagure API from my side projects (bodhi-rs, and the WIP koji-rs and pagure-rs). Though I think you'll probably want to have this dashboard powered by python, not by rust :)
While I love the concepts of Rust, I don't think there are that many benefits when mostly talking to HTTP or calling dnf/libsolv API. I wanted to learn some Rust via https://adventofcode.com/2019 but I have failed to delicate some time to that, nerdslipping and procrastinating differently :D
I was actually thinking Python + asyncio to collect the data + something like Angular to present them. However I'd rather go back and do adventofcode in Ook! than writing the JS frontend myself ;)
As a minimal viable product, I was thinking I could generate the data for the provided list of packages and given filter config file, and render the HTML statically via Jinja. That would work for my use case.
Let me know if you would like to discuss the backend design during the upcoming weeks. (To clarify: I'm on vacation, this is not strictly work related, but rather my winter holiday hobby project idea.)
Hi Miro,
I like your packaging dashboard a lot, I think this a good idea and an improvement for the packaging experience!
(Further replies below.)
Miro Hrončok mhroncok@redhat.com writes:
While I love the concepts of Rust, I don't think there are that many benefits when mostly talking to HTTP or calling dnf/libsolv API. I wanted to learn some Rust via https://adventofcode.com/2019 but I have failed to delicate some time to that, nerdslipping and procrastinating differently :D
Unless you are already quite proficient in Rust, it is probably more pragmatic to just use Python.
I was actually thinking Python + asyncio to collect the data + something like Angular to present them. However I'd rather go back and do adventofcode in Ook! than writing the JS frontend myself ;)
I've gathered a bit of experience with Typescript at $dayjob over the past months (unfortunately not with browsers and thus not actual frontend stuff), so if you're patient with me (and my limited time), I'd be willing to help out.
Cheers,
Dan
On 24. 12. 19 9:50, Dan Čermák wrote:
Hi Miro,
I like your packaging dashboard a lot, I think this a good idea and an improvement for the packaging experience!
Dan, thanks for your feedback and an offer to help.
Sorry for the very late reply.
Unfortunately, my idea to work on this during the winter holiday turned out to be non realistic. Hence the mockup is all I have so far and there is really nothing to help with, as nothing is going on.
I wish I had more time to devote to this, but frankly, I just don't :(
-
Dan Čermák -
Fabio Valentini -
Miro Hrončok