At the moment there is no way in CVS to organize bugs filed by developers to remind us of stuff we should fix, as far as I know.
In the past few days at least 3 such bugs were filed:
2000: %ProgramFiles% is not set in environment [me] 2003: WindowFromPoint Returns Wrong Window [rob] 2004: Bug In LVM_GETNEXTITEM(hWnd, -1, LVNI_FOCUSED | LVNI_SELECTED) [rob]
I think we should have a way to keep track of misc (small) buglets found but for whatever reason not fixed in bugzilla, so when one of us is bored (tee hee) there is a ready supply of nice descriptions of bugs probably with fixes described too.
Perhaps there should be a tracker bug for "Bugs filed by people with nice descriptions of what is wrong that are fixable in a reasonable timeframe by anyone", to separate out the random flotsam & jetsam that accumulates in bugzilla over time.
Thoughts?
thanks -mike
On February 10, 2004 07:00 am, Mike Hearn wrote:
Perhaps there should be a tracker bug for "Bugs filed by people with nice descriptions of what is wrong that are fixable in a reasonable timeframe by anyone", to separate out the random flotsam & jetsam that accumulates in bugzilla over time.
That's what keywords are IMO? And we already have one for them: tasklet. Does this solve your problem?
On Tue, 10 Feb 2004 09:02:26 -0500, Dimitrie O. Paun wrote:
That's what keywords are IMO? And we already have one for them: tasklet. Does this solve your problem?
Ah yes, tasklet seems closest to what I want. Just need to clean up the list a bit.
BTW, I note one of them is documenting debug channels. Maybe it'd be better to extend the WINE_*_DEBUG_CHANNEL macros to have a dummy parameter that a script can extract from the source to get one line descriptions of what they are, for instance:
WINE_DECLARE_DEBUG_CHANNEL(ole, "Trace COM, OLE and DCOM code");
obviously you wouldn't have to do this every time, just once somewhere for each channel.
Having said that I'm not sure it's really worth documenting then, given the technical nature of most of them and the need to be familiar with the given code to understand them anyway.
On Tue, 10 Feb 2004, Mike Hearn wrote:
Having said that I'm not sure it's really worth documenting then, given the technical nature of most of them and the need to be familiar with the given code to understand them anyway.
If we really need to document them we can do so directly in a file someplace (man page, etc), and we can have a script to tell us what's not documented, and what's obsolete. That's simple. The question is, as you said, is it worth doing it? Personally, I don't really think so.
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Mike Hearn