1) Setting up koji is a pain. Yes, there is a bunch of tools (ansible
playbooks, ssl cert generation in koji-tools, etc.) which make it easier
but they are not covered in the official docs.
2) hub code - it is a big file but there are no clear benefits of
refactoring it today. Original reason was related to cpython's ability to
quickly handle many files. It is not an issue anymore, on the other hand
there are no clear benefits for splitting. In the case of CLI I see it more
appropriate (file per command, etc.).
3) web UI - yes, this is a problem. While ago there was a short discussion
in koji-devel about creating a new web ui. As UI is completely independent
of the rest of the code, it is pretty ok to start separate project working
on it which wouldn't be affected by the slower release cycle of koji
itself. There are some pain points (except old tech) in current
implementation (proper web plugins are probably the foremost example) and I
would be pretty happy if someone will start to gather requirements. On my
(and probably Mike's also) side there is not much remaining capacity to
drive that. Saying that web UI is a second-class citizen is overstating but
it is definitely not top priority. I understand that it is the first thing
user see and it does a poor job in 2021/22. I'm open to facilitate starting
this project (and we can make it an item at a koji community meeting once
again).
4) token authentication - no problem - it would be pretty easy to add it.
It is a simple extension of user/password auth adding some crypto to that.
Nevertheless, I'm not sure if there is any real-world usage for that. For
testing purposes user/pw is enough, for any real installation ssl
certificates should be ok (koji-ssl-admin from koji-tools makes it pretty
easy). Anyway, I'm open to adding it.
5) I've made 1) short and want to expand it here. Documentation IS
confusing and it needs to get fixed. We've added a lot in the last year or
two but we're still maintaing old "howto" structures. Nowadays it is simply
incomprehensible. As a coincidence I've created
https://github.com/tkopecek/koji-docs-ng last week to start a new structure
and rewrite some parts. I want to keep it outside of koji for a while and
when we will be satisfied we can merge it to the main tree. Man pages
generated from CLI should be another part to be fixed which leads me to the
last UX item
6) CLI rewrite - Another discussion was about this and especially about
picking state-of-the-art CLI library. As often happens we've ended without
decision as nobody had enough time to explore current terrain. Part of this
effort should be the ability to automatically create man pages which should
also improve usability.
7) non-xmlrpc API - simply declined because of capacity. Maybe there could
be a separate project translating REST to XMLRPC as a workaround for such
usecases.
I would be happy for people getting on some of these tasks. I really try to
be as low barrier for contributors as possible declining only things which
are basically a) dangerous or b) potentially causing troubles in future.
Plan for koji next - PRs to
https://koji-planning.readthedocs.io or
discussion here or in community meetings.
Probably most simple way to get koji dev env working is to use "vagrant up"
from Ken's repo
https://github.com/ktdreyer/koji-playbooks
On Mon, Dec 6, 2021 at 7:34 AM Cappy Ishihara <cappy(a)cappuchino.xyz> wrote:
Thank you for your reply.
The code I have posted is but a prototype of what I'd want in something
like Koji or Copr, so of course flaws will be present, but thank you for
pointing them out anyways.
I am simply calling for an overhaul in the Koji codebase and I'm more than
happy that someone have reviewed my proposal and pointed out my flaws.
I will use this to plan for my future patches on Koji.
Anyways, is there any way that I can contribute to/any plans on the
development of Koji-NEXT? I'm very interested in a new revamped version of
Koji and I'd like to help out in that regard, especially in the API part.
P.S I also want some instructions on quickly deploying a test instance of
Koji for hacking.
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.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.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat