| 1 |
On Mon, Apr 13, 2020 at 4:12 AM Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> An example workflow is to: |
| 4 |
> |
| 5 |
|
| 6 |
Just picking this to reply to though this is more of a general comment |
| 7 |
on the two recent keywords threads. |
| 8 |
|
| 9 |
I get that this is Gentoo and we don't want to dictate how people do |
| 10 |
things. However, I feel like this is an area where we'd actually |
| 11 |
benefit from more direction. |
| 12 |
|
| 13 |
It seems like we're trying to support more different workflows for |
| 14 |
doing keywording/etc than we even have developers doing keywording in |
| 15 |
the first place. It seems like we probably have 5 people at any time |
| 16 |
doing actual arch testing but we're maintaining a lot of legacy |
| 17 |
code/etc to support 487 ways of going about arch testing because we |
| 18 |
don't want to upset somebody who probably doesn't actually do any arch |
| 19 |
testing. At the same time, we have no idea how the 5 people doing the |
| 20 |
actual work are actually doing their work, so we can't reliably ensure |
| 21 |
that their workflows don't break other than by making sure that we |
| 22 |
don't accidentally break any legacy behavior in any way. |
| 23 |
|
| 24 |
What I don't want to do is start a conversation where 27 devs |
| 25 |
(including myself) try to tell the people doing a lot of keywording |
| 26 |
work how to do their work. What I would love to see is the people who |
| 27 |
actually do keywording share how they actually go about it in |
| 28 |
practice, and then maybe try to document some kind of best practice |
| 29 |
around this and put it in the devmanual or in a GLEP or something. |
| 30 |
Then we can give that workflow more of a first-class support in our |
| 31 |
tooling and maybe worry less about others. |
| 32 |
|
| 33 |
I know I was completely taken by surprise by the idea that most |
| 34 |
keywording is done using tools these days, and that STABLEREQ isn't |
| 35 |
supposed to be a thing now. Not that these are bad things, but it |
| 36 |
seems to have been organic and not really formally transitioned. The |
| 37 |
devmanual no longer mentions the bugzilla keywords, but it also |
| 38 |
doesn't mention the bugzilla components and I didn't realize that you |
| 39 |
couldn't just turn an existing bug into a stable request just by |
| 40 |
adding STABLEREQ and copying arches. Obviously now I know but my |
| 41 |
point is more that it seems like this whole area would benefit from |
| 42 |
some kind of suggested workflow. |
| 43 |
|
| 44 |
Heck, this thread is also the first time I think I've seen "pkgcheck |
| 45 |
scan --commit" mentioned as a thing. I see that it was blogged about |
| 46 |
a few months ago, but I've stopped following planet Gentoo since |
| 47 |
Google reader died. Maybe we need a planet Gentoo mailing list or |
| 48 |
something. |
| 49 |
|
| 50 |
I guess my point is that there seem to be a lot of improved workflows |
| 51 |
out there, and we'd probably benefit from them being pointed out a bit |
| 52 |
more and mainstreamed. Those maintaining these tools would probably |
| 53 |
benefit as well if more people were using them as intended and they |
| 54 |
didn't have to maintain as much legacy compatibility simply because |
| 55 |
many don't realize there is a better way... |
| 56 |
|
| 57 |
-- |
| 58 |
Rich |
Archives