New bugzilla components.

[James Hawkins]

On Dec 16, 2007 4:08 PM, Kai Blin <kai.blin at gmail.com> wrote:
> On Sunday 16 December 2007 22:47:23 James Hawkins wrote:
>
> > ws2_32 or wsock32, or both, depending on the existing bugs.
>
> Given that wsock32 forwards over 90% of the calls to ws2_32, let's go for that
> one then.
>
> > > Coming to think about that, if we're fine to add more categories for
> > > things like secur32.dll, how about splitting up those by debug channel?
> > > E.g. my ntlm provider has an "ntlm" debug channel, the kerberos provider
> > > that I keep starting and restarting in some branches on my box always
> > > uses "kerberos", and Juan might want to use schannel as debug channel.
> >
> > I have to voice my disagreement on this one.  per-debug channel is too
> > fine-grained, and that's a road we don't want to go down.  Think of it
> > like this: the components are not meant to help the users in any way,
> > only the developers.
>
> But I as a part-time developer can't keep track of all the areas in Wine. I
> don't know anything about.. say GUI.. or actually anything that's not secur32
> or maybe winsock. Where's the advantage of me refiling a bug someone filed
> as.. say "ws2_32" to "default" again because I don't know what gui component
> is responsible as opposed to me refiling it as wine-gui (see bug 9771 as a
> specific example that just came up).
>

You refile it as misc/default so another developer who is more
familiar with the correct component can set the right component.
We're getting rid of wine-gui because wine-gui doesn't mean
anything...the bug description alone is enough to know that it's a gui
bug.

> > As a developer, will the different provider
> > components (ntlm, kerberos, et.al.) help you any?  You'll have to read
> > the logs anyway.
>
> Well, maybe. Once schannel is implemented, I probably won't look at those
> because I don't know about schannel. I don't get your point about having to
> read logs, because I think that is needed for all but the most obviously
> invalid bugs.
>

You said an advanced user could read the logs and set the provider
component based on the fixme's in the logs, and I'm saying that you'll
have to read the logs anyway, so the one advantage of that method is
taken away.

> > schannel, on the other hand, is a module in the wine
> > tree, so that would be a useful component.
>
> Nope. It forwards to secur32.dll, apart from two calls. I'm kind of certain
> we're just arguing about what color the bikeshed should be painted in, but
> either we just lump all sspi errors into one category, or we have one per
> logical module.
>

I have no idea about secur32, schannel, etc.  If schannel just
forwards to secur32, then there's no need for an schannel component,
and any bugs of that nature should be marked as secur32.  That still
doesn't mean we need an sspi component.

> So I guess the real question is how much diversity we want and need.
>

If most of the functionality is in secur32, where's the need for sspi,
and if there's more functionality in other modules besides secur32,
then there should be a component for each module that has a reported
bug.  Like I said before, I don't mind an sspi keyword.

-- 
James Hawkins