[stgt] [osd-dev] [PATCH 10/15 ver2] tgt: os.h: getnameinfo() is different on none-Linux systems

[FUJITA Tomonori]

On Thu, 12 Mar 2009 10:49:12 +0200
Boaz Harrosh <bharrosh at panasas.com> wrote:

> > Think about Linux kernel development; for example, vfs has a bug and
> > you develop your file system. You need to fix the vfs bug. You should
> > not add the workaround to your file system code to avoid the bug.
> > 
> 
> This is the wrong example. You say something right and you think it will
> win the argument. But it must be relevant, this example is not relevant.
> 
> What I'm saying is that if I develop a filesystem, and I find something that can
> be done nicer, a cleanup to vfs code. I separate the two efforts. One patch will
> do the cleanup and, one or more patches will be submitted to the FS. If after the
> cleanup also the FS code needs to change then there will be a patch done for that,
> as to other FSs that might need to change because of the cleanup.
> 
> I want BSD compatibility patches to not change ANYTHING, What is so hard
> to understand, patches that change something should be SEPARATE.

You are completely wrong again.

We don't talk about cleanups. You suddenly start talking about with
cleanups.

We are talking about improving tgt. With improvement, we don't need
BSD compatibility. So there is no reason to add BSD compatibility
in the first place.

Your logic is completely crazy to me. I will not merge your work if
you don't change your way.


> >> If you want to fix the Linux code then it should be done separately,
> >> by itself. In a different patchset. Which only fixes the Linux code.
> >> This way if you have a regression you can go back to something that
> >> worked before. Then if the Linux is fixed in a way compatible to BSD,
> >> the compatibility layer can be removed by a latter patch.
> >>
> >> Never MIX code changes with compatibility changes, because you cannot
> >> separate the two if something goes wrong.
> >>
> >> So what? Are you going to wait for all the Linux hacks and bugs fixed until
> >> you put the BSD code? this is not the way to work!
> > 
> > This is the way to work. You should fix the root problems.
> > 
> 
> But there's never been a problem. This code works for years just fine.
> The problem at hand is BSD compatibility. As I said changes should be
> separate, cleanups is one thing, BSD code another. Most of the patches
> are BSD only stuff why can't they go in, they do nothing to the code.

The logic is broken. Working code doesn't mean that we don't need to
improve it.


> >> Mean while I'm using my tree, and so will my users
> > 
> > Drop such attitude; my code works for my users. I don't care about
> > your users. I care about only tgt.
> 
> No! you drop your attitude. These are your users, hell I'm your user.
> I came with a problem, BSD. Now you queue me behind bureaucracy and
> second grade users. But there is one philosophical question you must
> answer: where was this problem before I came with BSD code?

See above. Working code doesn't mean that there is no room to improve.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html