Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hi Andreas and Ralf,
On Mon, Jul 17, 2023 at 04:08:48PM +0200, Ralf Treinen wrote:
> > Moving the usertag to the qa namespace sounds like a good idea.
>
> I agree
Thank you
> Sounds like a good idea. However, I do not think that usertags support
> a hierarchy of tags. So maybe different specific usertags with a common
> prefix, like
>
> fileconflict-installation (error occurs when one tries to install two
> packages togther)
> fileconflict-upgrade (error occurs when upgrading, due to missing
> breaks/replaces)
> fileconflict-directory (error occuring due to /usr merge)
Can either of you elaborate on the need to further classify the kind of
conflict (file / directory / symlink / ...) or the kind of cause
(installation / upgrade / ...)?
Are you ok with explicitly excluding issues that only arise as a result
of /usr-merge. These have a temporary cause and will vanish before too
long. Due to the automatic bug filing that I hope to be doing, I need
very precise tagging for them.
Often times, it is initially not trivial to figure out whether a
conflict only arises from installation or upgrades. Rather I propose to
have a grab-bag tag for all of them. That allows us to move forward with
less complexity and makes it easier to understand for everyone. Most of
these issues result in an unpack error one way or another, but the
symlink vs something else conflicts may result in unpack-dependent
behaviour.
I think we have consensus on using the debian-qa list, but I've seen
file-overwrite and fileconflict-* as proposals with varying
subclassification now. While we don't have a tag hierarchy on a
technical level, Paul indicated that we may establish a hierarchy using
processes. Using fileconflict makes it easy to establish a
fileconflict-* subclassification later (by having the qa bot
automatically add the super tag when it sees a sub tag).
Is this convincing enough to move forward with the generic
debian-qa@lists.debian.org usertag fileconflict rather than something
more detailed? Is this also convincing enough to extend it to cover
non-file conflicts or do you want a different tag for that? Should the
tag also cover m-a:same file conflicts?
I certainly won't object to doing a subclassification and I'm happy to
add the subclass tags if doing so does not incur unreasonable
implementation cost, but I don't want to participate in designing them
nor updating existing tags. My need here is automatically ignoring
detected issues that already are reported and the generic variant is
sufficient for doing that.
Helmut
Reply to: