DO NOT REPLY [Bug 3392] fuzzy misbehaving if source is a file

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=3392





------- Comment #12 from egmont at uhulinux.hu  2006-03-16 04:52 MST -------
I do agree that there are cirsumstances when fuzzy doesn't speed up things,
or actually causes huge performance regression. On the other hand, as I
described, there are also cases when it really helps a lot. It should be up to
the users to choose whether to use it or not.

You said:
> I don't want the file-set that fuzzy compares against to be made
> larger by default.

I perfectly agree. I never talked about the _default_. I talked about the case
where --compare-dest=... is also specified in addition to --fuzzy. This is
clearly not the default, in this case the user explicitely asks for a larger
file set to be fuzzy-compared to, hopefully knowing its pros and cons.

About netiquette:

I have seen several netiquettes, mostly about e-mail, but I can't remember
seeing a bug-reporting netiquette anywhere. Please point me to an URL, I'll be
happy to read it and follow its guidelines.

First I reopened the bug since it was closed falsely, the bug mentioned in the
original report is _not_ fixed (comment #5).

For the second time (comment #7) I reopened it to (1) note that rsync doesn't
mention its current behavior in its docs and doesn't refuse options that don't
work together, and (2) to state that your arguments containing "IMO" and
"I want to leave it..." are not quite strong arguments. For (1) I could have
opened another report, I think it's quite a matter of taste. Some prefer to
split each and every single step of a bigger problem set to a different issue,
some rather want to see "co-operation of --compare-dest and --fuzzy" as one
large bug that says: all details of this problem set should be solved. Seems
that you belong to the first group, while I belong to the second one. Note
that opening a new issue has at least one drawback: the cc list is lost.
I think anyone who was interested in the first report is still interested in
how fuzzy and compare-dest will work together.

By the way: there are other ways to close a bug, there is INVALID, there is
WONTFIX etc. These are not in netiquette, these are in the manual and UI of
bugzilla. Still you chose FIXED. Why? Please read the _original_ report once
again. It is _not_ fixed.

The third time I commented (comment #10), _before_ you told it's rude to reopen
bugs, I did _not_ reopen it, neither do so now.

Do you think that closing a bug twice in the middle of a conversation, while
that bug is not yet fixed, is not a rude action at all? Especially in
comment #6 where you had no real argument at all, just a personal taste?

> Thanks for you input, and feel free to open an enhancement request for the
> --fuzzy option if you'd care to do so.

So, if rsync doesn't work the way it should is not a bug, fixing it is only an
enhancement request? And if I open a new bug then it is likely to be fixed
(ohh, sorry, implemented as a new feature) but if I tell about it here then it
will be forgotten? Despite that I still do not ask for anything more than to
fix what I reported in my _original_ submission in this topic? Shall I really
open another report of the same problem that I originally reported here?

Sorry, I got tired of it. I'm happy to help the free software community
anywhere, sometimes with bug reports or enhancement requests, sometimes with
patches, sometimes with new sourcecode, with translations, or a lot of other
stuff, but only as long as I don't keep on hitting walls during my work.
I have no time and no power to try to fight against people who try to offend
my requests or my work. It's clear that you do not want to fix it. I cannot
force you to do. So just don't fix it. Leave it as it is now. Leave it as
CLOSED _FIXED_ (khmmm). And let's forget this whole issue...


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.