package: bugs.debian.org
severity: normal

Hi, I've been noticing these issues on and off when doing control
server commands, but got a whole string of issues when dealing with
#693894, so I've decided to document them.  If you want me to split
this into multiple bugs, please let me know.

The first issue was when Josselin uploaded the fix.  At that time, the
bug was assigned to nautilus-open-terminal, but the fix was included
in a gsettings-desktop-schemas upload.  So, after that the bug was in
package nautilus-open-terminal, but marked as fixed in
gsettings-desktop-schemas/3.4.2-3.  I wonder if these types of
situations could be improved by automatically reassigning bugs when
they're fixing in other packages?  Although I suppose a consequence
would be unexpected behavior in the case of a typos in the closes:
number in changelogs.  Maybe the right thing is to not close bugs that
are fixed in packages that the bug isn't assigned to, and send a mail
stating that.

My first command was merging a duplicate report (also assigned to
nautilus-open-terminal).  That went as I expected.
Merged 693894 694128

My next command was reassigning the bug to the the right package
(gsettings-desktop-schemas), which marked the bug as notfound in
nautilus-open-terminal, but also unexpectedly marked the bug as no
longer fixed in gsettings-desktop-schemas/3.4.2-3
Bug reassigned from package 'nautilus-open-terminal' to
'gsettings-desktop-schemas'.
No longer marked as found in versions nautilus-open-terminal/0.19-2.
No longer marked as fixed in versions gsettings-desktop-schemas/3.4.2-3.

So my next step was to correct that, and also set the found
information.  The found command unexpectedly reopened the bug (I
suppose because there was no fixed info at that time, and I suppose I
could train myself to put fixed lines first, but that's a bit
tedious).
Marked as found in versions gsettings-desktop-schemas/3.4.2-2 and reopened.
Marked as fixed in versions gsettings-desktop-schemas/3.4.2-3.

Then I closed the bug, and that of course went as expected.
Marked Bug as done

Thanks for looking into these issues.

Best wishes,
Mike

No, because typos will end up in bugs migrating from package to
package. In general, you should reassign the bug before you close it.

Right, because generally when you reassign, the version information is
wrong. It would be reasonable to keep the version information if it
matched the package which the bug was assigned to, but that requires
extra logic.

See the documentation of found;[1] if the highest found version is
greater than the highest fixed version, the bug shouldn't be closed,
so it is automatically reopened. Set fixed versions first if you want
this to happen.


Don Armstrong

1: http://www.debian.org/Bugs/server-control#found

That's exactly what I said and why I offered proposed the secondary
more ideal solution, which would be to not close bugs that are
assigned to different packages than the upload itself.  Is there a
reason not to do that?

Agreed, it wasn't my mistake, I just came in to correct it.

This would be nice.

Point being that it's rather easy to forget ordering relevance, and
it's not very intuitive anyway.  Would it be possible to define
something akin to aritmetic operator ordering (i.e. addition follows
multiplication).  So, on receiving a

found x y
fixed w z

The server would consider operator ordering and automatically reformat
the message to

fixed w z
found xy

Best wishes,
Mike

There are some bugs (like wnpp bugs) which are closed by an upload in
a different package, for example. It seems reasonable to send out a
warning, but I don't want to disallow it.

Each control line operates in isolation; changing that would require a
huge redesign of how control works, and would also make it much more
brittle.


Don Armstrong

Would a disallow by default but a whitelist things like wnpp also add
too much complexity?

Wouldn't it simply be a matter of adding a first pass that rewrites
the message with lines in the correct order?

Best wishes,
Mike

Yes, unfortunately. I'll probably handle this eventually by supporting
limit for -done.

Figuring out what the intended order is is very difficult. In simple
cases, it's easy enough, but once you add the complexity of clones and
cases where you actually want the side effects of found, it is very,
very difficult.

Far easier for humans just to use the right commands.


Don Armstrong