From: Kent Fredric <kentnl@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Keywordreqs and slacking arch teams
Date: Sun, 29 Dec 2019 00:05:43 +1300 [thread overview]
Message-ID: <20191229000543.001631d9@katipo2.lan> (raw)
In-Reply-To: <20191228093509.GB2033@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]
On Sat, 28 Dec 2019 10:35:09 +0100
Fabian Groffen <grobian@gentoo.org> wrote:
> Hmmm, interested to hear what kind of things you're thinking about here.
A lot of the "Work" of filing a keyword request is modelling all the
consequential keywordings that have to take place.
If there was say, a web based UI, that:
- Automatically determined which packages are ready for stabilization
due to all their dependencies already being stable (and maybe with
automatic cooldown-from-testing detection )
- Automatically determined which packages can be keyworded without
additional work due to all their dependencies being keyworded
- When requesting keywording/stabilization, automatically determined
what all the consequences are and what else needs to be keyworded to
satisfy it
- Allowed a simple "Add keyword(s) <y..> for package <x>" interface,
that intelligently created an issue and a target list, and then once
the list was built, constantly ensured the list to be valid, or
determined automatically when sub-work was completed and reducing the
published list automatically, and then responded to potential issues
based on changes in git, ( as opposed to being only triggered when
the bug was touched )
Most of the "pain" and legwork required by maintainers would go away.
As it is, I feel a lot of us are reproducing a lot of logic that is
rather routine and could be automated.
But the overall idea here is to orient the point of keyword-requests in
some way to focus on the primary objective, where the developer
indicates their intent, and the system's job is to facilitate that
intent coming to fruition, pointing out problems on its own.
( I have somewhat hacked together some perl scripts for myself for some
of these tasks, but the command-line interface is not ideal for this
workflow, and the code is not in a condition I can share it, and I
don't think perl is the right language to address this problem with )
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-12-28 11:06 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-28 7:09 [gentoo-dev] Keywordreqs and slacking arch teams Michał Górny
2019-12-28 9:27 ` Kent Fredric
2019-12-28 9:35 ` Fabian Groffen
2019-12-28 11:05 ` Kent Fredric [this message]
2019-12-28 11:14 ` Michael 'veremitz' Everitt
2019-12-28 11:27 ` Kent Fredric
2019-12-28 11:40 ` James Le Cuirot
2019-12-28 11:44 ` Kent Fredric
2019-12-28 11:32 ` Kent Fredric
2019-12-28 11:35 ` Michael 'veremitz' Everitt
2019-12-28 11:42 ` Kent Fredric
2019-12-28 18:05 ` Alec Warner
2019-12-29 2:19 ` Aaron Bauman
2019-12-29 5:09 ` Kent Fredric
2019-12-30 1:45 ` A Schenck
2020-01-02 20:32 ` Rolf Eike Beer
2020-01-02 23:25 ` Mike Pagano
2020-01-02 23:35 ` Rolf Eike Beer
2020-01-03 0:19 ` Michael 'veremitz' Everitt
2020-01-03 2:40 ` Aaron Bauman
2020-01-03 10:00 ` Rolf Eike Beer
2020-01-04 11:09 ` Rolf Eike Beer
2020-01-04 11:25 ` Michael 'veremitz' Everitt
2020-01-04 13:35 ` Rolf Eike Beer
2020-01-03 14:37 ` [gentoo-dev] Vanilla sources Michael Orlitzky
2020-01-03 14:40 ` Toralf Förster
2020-01-03 14:41 ` Michael Orlitzky
2020-01-03 14:46 ` Rich Freeman
2020-01-03 14:48 ` Toralf Förster
2020-01-03 22:32 ` Michael 'veremitz' Everitt
2020-01-04 7:38 ` Hanno Böck
2020-01-04 18:39 ` William Hubbs
2020-01-04 18:41 ` Michał Górny
2020-01-07 8:52 ` Hanno Böck
2020-01-03 14:52 ` Michael Orlitzky
2020-01-03 14:55 ` Michael Orlitzky
2020-01-03 16:28 ` Aaron Bauman
2020-01-04 11:01 ` Rich Freeman
2020-01-04 11:42 ` Roy Bamford
2020-01-04 12:54 ` Rich Freeman
2020-01-04 13:08 ` Roy Bamford
2020-01-04 13:43 ` Thomas Deutschmann
2020-01-05 10:34 ` Roy Bamford
2020-01-04 20:13 ` Christopher Head
2020-01-04 20:39 ` Rich Freeman
2020-01-04 13:47 ` Thomas Deutschmann
2020-01-04 18:41 ` William Hubbs
2020-01-04 18:42 ` Michał Górny
2020-01-04 19:13 ` Rolf Eike Beer
2020-01-05 16:41 ` Michael Orlitzky
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=20191229000543.001631d9@katipo2.lan \
--to=kentnl@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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