Hello, Am Montag, 21. Oktober 2019, 11:40:05 CEST schrieb Simon Lees:
On 10/21/19 7:54 PM, Jan Engelhardt wrote:
On Monday 2019-10-21 10:19, Ludwig Nussel wrote:
Looking at the discussion here I can already foresee the next fights in submit requests where people argue over which tags to put on a package.
You can't have it both ways. Either people fight over the entry's value, or they don't care. History tells me they staticially won't care.
Exactly. That's why I'd atually love to see such a tag fight, because it would indicate that someone cares about these tags ;-)
So I wonder whether to maybe dodge that mine field completely and store tags aka groups outside of packages.
Outside of packages is disconnected metadata, and there seems to be a reservation about such, depending on the interpretation of https://lists.opensuse.org/opensuse-factory/2019-10/msg00115.html
This is just an illustration in the past that people haven't put in the effort to create / keep the data up to date, from looking at the state of our current group system i'm pretty sure the same arguments apply, yes its slightly better because everything has something (if everything having something is even better) but much of the data is inconsistent garbage because people have just picked the easiest path to making a bot happy (and many have complained about it to this list), now that the bot's gone I don't see it being any different unless people who aren't maintainers step up to keep it good
I have no idea how many make-the-bot-happy groups we have in our packages, but (after a quick check on several of the packages I have installed) I'd guess that at least 95% of our packages have a sane group. (Of course it's easier and more entertaining to point out some packages with a "wrong" group than listing all the packages with a correct or good-enough group.) For comparison - we have 1126 RPMs with appdata (number from Stefan Brüns somewhere else in this discussion). Compare that to 12455 source packages in openSUSE:Factory, and you'll get that only 9% of our source packages have appdata. For the resulting RPMs, the number is even worse because a source package can produce multiple RPMs (see texlive-spec-* for some extreme variants ;-)
If people other then maintainers are going to step up and do it in many way's it makes sense for it to be done in a way maintainers don't need to touch it.
I disagree on the idea of moving the group/tags outside of the spec file. If it is in the spec file, then lots of maintainers will "accidently" add or adjusts the group/tags because it's easy and not much work. If it's somewhere external, that's quite some (too much?) work ("why should I jump through another loop?"), and we'll for sure get the result that "package maintainers don't care about groups/tags". Even if a maintainer doesn't care, he/she'll probably accept a SR that updates the group/tags - and if it's only because declining it might result in getting it reopened etc. which means more work ;-) Therefore I'd really prefer to keep the group/tags/whatever in the spec file. We have a somewhat similar situation with the openSUSE infrastructure where information about each VM is split up across multiple places (pages in our internal wiki and in the salt pillar/id/ files). In practise, only the salt files get updated (because that's what is used in production) while the wiki pages are terribly outdated. I'm currently working on moving the content of the VM-specific wiki pages to the salt pillar/id/ files. Besides having all information about a VM in one place, it has the big advantage that someone who edits the salt file most probably keeps the whole file up-to-date. The chance that someone updates the wiki page is much smaller. This change is quite new and still has to prove itsself as working, but OTOH we already know that splitting information across multiple places lead to terribly outdated information in our internal wiki - simply because people forget to update all places, or are too lazy to do it.
If a group of non maintainers are willing to keep metadata up to date inside packages then they will be willing to externally as well.
Hmmm, meine Glaskugel ist schon wieder in der Spülmaschine.... Hallo Volker - wo gibt es solche Glaskugeln?
They'll have much less work if the metadata is kept in the spec file, because lots of maintainers will "accidently" maintain it, even if they don't care too much. Regards, Christian Boltz -- trotz Spülmaschine, 100% Trefferquote :-)) [> Volker Kroll und Herbert Schrader in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org